Replies: 5 comments 1 reply
-
|
This looks like a tagging mistake, I think? Ways in a multipolygon should only be tagged if they have a separate identity. So, for example, https://www.openstreetmap.org/relation/11267 is https://www.openstreetmap.org/relation/13836007 has all the windfarm tags, but its constituent way https://www.openstreetmap.org/way/1033955443 has them as well. This is wrong - if the tags are on the multipolygon relation, they shouldn't be repeated on the way. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Perhaps your example relation is a better illustration of my problem if I were to wish to select places of learning (universities and schools, and also to select areas tagged landuse=grass, then I think I will have the same problem - the inner grass area will be preresented as part of the multipolygon for the relation, and separately as a way selected for the tag landuse=grass. I would be unable to access the relation with NextRelation because it is not availiable in the relation_scan_function(), and therefore I am a) determine that the selected way is actually part of a "pseudo way" representing the multipolygon. Its possible I'm missing something here, which is why I'm asking the question [EDIT} |
Beta Was this translation helpful? Give feedback.
-
You are misunderstanding. The university building relation will be presented to way_function as an object with a hole in it. That is because the multipolygon has a hole in it (an "inner"). The grass will be presented to way_function as an object representing the shape of the grass. It would be wrong to present the building without a hole in it, because the building has a hole in it.
No there isn't, please don't tell me I don't know how OSM data works. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Richard,
Ive chosen to respond via email as I dont believe it'd be helpful to reply
to your response on the forum:
I'm most certainly not implying you dont know how OSM data is supposed to
work, and I apologise if that was the impression i gave you. Nonetheless,
the situation exists, and will most likely continue to do so until some
rule (i dont care which) is actually enforced by the relevant tooling. I
should point out that, while a relative novice with regard to OSM, I do
have some experience in designing IT solutions, so I would appreciate a
slightly more collaborative response (though I appreciate you dont know me
from Adam, hence my private response) . For now I'll accept that my reply
was poorly worded, and for that I again apologise.
I fully recognise my incomplete understanding of OSM data and how to best
use that data, which was the basis for my request for help/suggestions, but
in all honesty, "its been tagged wrong" is not an answer; at best its
dismissive. if it's THAT "wrong", then it shouldn't be possible. Simplistic
I know, but there IS a valid argument for a parent/child relationship where
both have the same categorisation in the real world, and any model of the
real world either needs to accept that, or make an "adjustment" for it
(such as "superroute" and "route", and i can cite a great many more). No
such acknowledgement or adjustment exists in the case of wind farms (as
just one example), so far as I can see (either in principle or in fact).
So where to go from here? (in the end I'm interested in progress not
disagreements). as things stand I have the following possible outcomes:
1) produce polygons for individually tagged windfarm areas, and duplicate
multipolygons for tagged multipolygons (relations) for the grouping of
"associated" areas.
2) not capturing any windfarms that are multipolygons (thereby missing any
that have untagged child polygons - either closed ways, or multiple ways
comprising a polygon)
Neither of these is particularly great in my use-case, although #1 is
marginally preferable.
The ideal solution would be to be able to skip any selected way polygons
that are actually members of multipolygon relations, AND to be able to
split multipolygons into their constituent polygons/lines as individual
features. Perhaps a little pie in the sky I admit, but it's a target to
which I'd like to be able to get closer. Hopefully so far as no duplicates
and no lost data.
Thank you though for your explanation of how the "university" example is
"delivered" in lua. Helps my understanding greatly without having to do yet
more experimentation or making poor assumptions.
I'll keep toying with this, since I need to find a sensible and workable
solution that delivers complete and concise results. If I get anywhere I'll
be sure to let you know, Similarly if I have any further queries.
Again apologies if you perceived criticism in my previous reply, none was
intended. I really hope to find a way forward with this, as tilemaker is
far and away the simplest/best tooling I've found so far for my needs
(maritime vector charting).
Cheers.
Ed Jones
PS Im no great fan of email/forums as a means of discussing like this. If
you're willing I'm happy to discuss by phone, just say (though i fully
understand if you'd prefer not).
And now I've spent too long fiddling with the "tone" of this email, so
apologies once more (final time!) if I've given any offence - I'm quite
capable of coping with being called an eejit so don't worry about that,
Please understand, what I'm hoping to find here is a way forward, not an
argument (although I should point out that's a two way street).
And now I'm rambling, so I'll leave you in peace for now.
…On Tue, 13 Aug 2024 at 20:00, Richard Fairhurst ***@***.***> wrote:
if I were to wish to select places of learning (universities and schools,
and also to select areas tagged landuse=grass, then I think I will have the
same problem - the inner grass area will be preresented as part of the
multipolygon for the relation, and separately as a way selected for the tag
landuse=grass.
You are misunderstanding.
The university building relation will be presented to way_function as an
object with a hole in it. That is because the multipolygon has a hole in it
(an "inner").
The grass will be presented to way_function as an object representing the
shape of the grass.
It would be wrong to present the building without a hole in it, because
the building has a hole in it.
there is an equally valid argument
No there isn't, please don't tell me I don't know how OSM data works.
—
Reply to this email directly, view it on GitHub
<#741 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2GP64ELQN52HM6PYCIZ23ZRJJV3AVCNFSM6AAAAABMN2JUJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZSHE2TOMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Ed,
if it's THAT "wrong", then it shouldn't be possible
That's not how OSM works. OSM does not enforce data integrity serverside. The expectation is that mappers and data consumers will collaboratively evolve standards. If a mapper departs from these informal standards, then it won't render correctly. There is no expectation that the OSM API and central database will be anything other than a transport and distribution mechanism.
Possibly what is wrong here is that the windfarms should be mapped individually (whether as ways or multipolygons) and then grouped in a site relation, but I haven't looked into it, partly because it appears to be infested with seamark tagging which has been broken since day one. If you want individual tagging advice then please use community.openstreetmap.org.
Richard
…On 13 Aug 2024, 23:49 +0100, sombell ***@***.***>, wrote:
Richard,
Ive chosen to respond via email as I dont believe it'd be helpful to reply
to your response on the forum:
I'm most certainly not implying you dont know how OSM data is supposed to
work, and I apologise if that was the impression i gave you. Nonetheless,
the situation exists, and will most likely continue to do so until some
rule (i dont care which) is actually enforced by the relevant tooling. I
should point out that, while a relative novice with regard to OSM, I do
have some experience in designing IT solutions, so I would appreciate a
slightly more collaborative response (though I appreciate you dont know me
from Adam, hence my private response) . For now I'll accept that my reply
was poorly worded, and for that I again apologise.
I fully recognise my incomplete understanding of OSM data and how to best
use that data, which was the basis for my request for help/suggestions, but
in all honesty, "its been tagged wrong" is not an answer; at best its
dismissive. if it's THAT "wrong", then it shouldn't be possible. Simplistic
I know, but there IS a valid argument for a parent/child relationship where
both have the same categorisation in the real world, and any model of the
real world either needs to accept that, or make an "adjustment" for it
(such as "superroute" and "route", and i can cite a great many more). No
such acknowledgement or adjustment exists in the case of wind farms (as
just one example), so far as I can see (either in principle or in fact).
So where to go from here? (in the end I'm interested in progress not
disagreements). as things stand I have the following possible outcomes:
1) produce polygons for individually tagged windfarm areas, and duplicate
multipolygons for tagged multipolygons (relations) for the grouping of
"associated" areas.
2) not capturing any windfarms that are multipolygons (thereby missing any
that have untagged child polygons - either closed ways, or multiple ways
comprising a polygon)
Neither of these is particularly great in my use-case, although #1 is
marginally preferable.
The ideal solution would be to be able to skip any selected way polygons
that are actually members of multipolygon relations, AND to be able to
split multipolygons into their constituent polygons/lines as individual
features. Perhaps a little pie in the sky I admit, but it's a target to
which I'd like to be able to get closer. Hopefully so far as no duplicates
and no lost data.
Thank you though for your explanation of how the "university" example is
"delivered" in lua. Helps my understanding greatly without having to do yet
more experimentation or making poor assumptions.
I'll keep toying with this, since I need to find a sensible and workable
solution that delivers complete and concise results. If I get anywhere I'll
be sure to let you know, Similarly if I have any further queries.
Again apologies if you perceived criticism in my previous reply, none was
intended. I really hope to find a way forward with this, as tilemaker is
far and away the simplest/best tooling I've found so far for my needs
(maritime vector charting).
Cheers.
Ed Jones
PS Im no great fan of email/forums as a means of discussing like this. If
you're willing I'm happy to discuss by phone, just say (though i fully
understand if you'd prefer not).
And now I've spent too long fiddling with the "tone" of this email, so
apologies once more (final time!) if I've given any offence - I'm quite
capable of coping with being called an eejit so don't worry about that,
Please understand, what I'm hoping to find here is a way forward, not an
argument (although I should point out that's a two way street).
And now I'm rambling, so I'll leave you in peace for now.
On Tue, 13 Aug 2024 at 20:00, Richard Fairhurst ***@***.***>
wrote:
> if I were to wish to select places of learning (universities and schools,
> and also to select areas tagged landuse=grass, then I think I will have the
> same problem - the inner grass area will be preresented as part of the
> multipolygon for the relation, and separately as a way selected for the tag
> landuse=grass.
>
> You are misunderstanding.
>
> The university building relation will be presented to way_function as an
> object with a hole in it. That is because the multipolygon has a hole in it
> (an "inner").
>
> The grass will be presented to way_function as an object representing the
> shape of the grass.
>
> It would be wrong to present the building without a hole in it, because
> the building has a hole in it.
>
> there is an equally valid argument
>
> No there isn't, please don't tell me I don't know how OSM data works.
>
> —
> Reply to this email directly, view it on GitHub
> <#741 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC2GP64ELQN52HM6PYCIZ23ZRJJV3AVCNFSM6AAAAABMN2JUJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZSHE2TOMA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
thanks for the speedy reply.
I can't help but agree that the seamark tagging, to say the least, what
haphazard in some areas - which makes rigorous consumption of the data
problematic at times!
In the meantime I'll cope with some replication of features rather than
lose otherwise valid data.
Cheers
Ed
On Wed, 14 Aug 2024, 10:03 Richard Fairhurst, ***@***.***>
wrote:
… Hi Ed,
> if it's THAT "wrong", then it shouldn't be possible
That's not how OSM works. OSM does not enforce data integrity serverside.
The expectation is that mappers and data consumers will collaboratively
evolve standards. If a mapper departs from these informal standards, then
it won't render correctly. There is no expectation that the OSM API and
central database will be anything other than a transport and distribution
mechanism.
Possibly what is wrong here is that the windfarms should be mapped
individually (whether as ways or multipolygons) and then grouped in a site
relation, but I haven't looked into it, partly because it appears to be
infested with seamark tagging which has been broken since day one. If you
want individual tagging advice then please use community.openstreetmap.org.
Richard
On 13 Aug 2024, 23:49 +0100, sombell ***@***.***>, wrote:
> Richard,
>
> Ive chosen to respond via email as I dont believe it'd be helpful to
reply
> to your response on the forum:
>
> I'm most certainly not implying you dont know how OSM data is supposed
to
> work, and I apologise if that was the impression i gave you.
Nonetheless,
> the situation exists, and will most likely continue to do so until some
> rule (i dont care which) is actually enforced by the relevant tooling. I
> should point out that, while a relative novice with regard to OSM, I do
> have some experience in designing IT solutions, so I would appreciate a
> slightly more collaborative response (though I appreciate you dont know
me
> from Adam, hence my private response) . For now I'll accept that my
reply
> was poorly worded, and for that I again apologise.
>
> I fully recognise my incomplete understanding of OSM data and how to
best
> use that data, which was the basis for my request for help/suggestions,
but
> in all honesty, "its been tagged wrong" is not an answer; at best its
> dismissive. if it's THAT "wrong", then it shouldn't be possible.
Simplistic
> I know, but there IS a valid argument for a parent/child relationship
where
> both have the same categorisation in the real world, and any model of
the
> real world either needs to accept that, or make an "adjustment" for it
> (such as "superroute" and "route", and i can cite a great many more). No
> such acknowledgement or adjustment exists in the case of wind farms (as
> just one example), so far as I can see (either in principle or in fact).
>
> So where to go from here? (in the end I'm interested in progress not
> disagreements). as things stand I have the following possible outcomes:
> 1) produce polygons for individually tagged windfarm areas, and
duplicate
> multipolygons for tagged multipolygons (relations) for the grouping of
> "associated" areas.
> 2) not capturing any windfarms that are multipolygons (thereby missing
any
> that have untagged child polygons - either closed ways, or multiple ways
> comprising a polygon)
>
> Neither of these is particularly great in my use-case, although #1 is
> marginally preferable.
>
> The ideal solution would be to be able to skip any selected way polygons
> that are actually members of multipolygon relations, AND to be able to
> split multipolygons into their constituent polygons/lines as individual
> features. Perhaps a little pie in the sky I admit, but it's a target to
> which I'd like to be able to get closer. Hopefully so far as no
duplicates
> and no lost data.
>
> Thank you though for your explanation of how the "university" example is
> "delivered" in lua. Helps my understanding greatly without having to do
yet
> more experimentation or making poor assumptions.
>
> I'll keep toying with this, since I need to find a sensible and workable
> solution that delivers complete and concise results. If I get anywhere
I'll
> be sure to let you know, Similarly if I have any further queries.
>
> Again apologies if you perceived criticism in my previous reply, none
was
> intended. I really hope to find a way forward with this, as tilemaker is
> far and away the simplest/best tooling I've found so far for my needs
> (maritime vector charting).
>
> Cheers.
> Ed Jones
>
> PS Im no great fan of email/forums as a means of discussing like this.
If
> you're willing I'm happy to discuss by phone, just say (though i fully
> understand if you'd prefer not).
> And now I've spent too long fiddling with the "tone" of this email, so
> apologies once more (final time!) if I've given any offence - I'm quite
> capable of coping with being called an eejit so don't worry about that,
> Please understand, what I'm hoping to find here is a way forward, not an
> argument (although I should point out that's a two way street).
>
> And now I'm rambling, so I'll leave you in peace for now.
>
> On Tue, 13 Aug 2024 at 20:00, Richard Fairhurst ***@***.***>
> wrote:
>
> > if I were to wish to select places of learning (universities and
schools,
> > and also to select areas tagged landuse=grass, then I think I will
have the
> > same problem - the inner grass area will be preresented as part of the
> > multipolygon for the relation, and separately as a way selected for
the tag
> > landuse=grass.
> >
> > You are misunderstanding.
> >
> > The university building relation will be presented to way_function as
an
> > object with a hole in it. That is because the multipolygon has a hole
in it
> > (an "inner").
> >
> > The grass will be presented to way_function as an object representing
the
> > shape of the grass.
> >
> > It would be wrong to present the building without a hole in it,
because
> > the building has a hole in it.
> >
> > there is an equally valid argument
> >
> > No there isn't, please don't tell me I don't know how OSM data works.
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <
#741 (comment)>,
> > or unsubscribe
> > <
https://github.com/notifications/unsubscribe-auth/AC2GP64ELQN52HM6PYCIZ23ZRJJV3AVCNFSM6AAAAABMN2JUJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZSHE2TOMA>
> > .
> > You are receiving this because you authored the thread.Message ID:
> > ***@***.***>
> >
> —
> Reply to this email directly, view it on GitHub, or unsubscribe.
> You are receiving this because you commented.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#741 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2GP67S537NGWC4LLLNK7DZRMMMNAVCNFSM6AAAAABMN2JUJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZTGQ4TQMY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Having read through the documentation I understand that Relations with a type "multipolygon" are handled by tilemaker by delivering them to the lua scrpit so they are processed by the way_function() as ways.
My problem is that the child polygons are also tagged such thay get selected for processing by way_function() as well. This results in two rendered polygons for each of the child polygons (one from the child way, and one from the parent relation).
The specific case I'm dealing with can be represented by the following relation and its children (OSM Id: 13836007).
As you can see both the relation and the child features are tagged with:
This means (in this case) that i get a way for each of the child ways, and one for the relation.
I could skip any "pseudo ways" from multipolygon relations by ignoring any with the type == "multipolygon" tage, but then I run the risk of losing multipolygon relations where the child features are not tagged such that they will be selected. and I dont see a way to process these multipolygon relations as relations with child polygons.
It seems that multipolygon relations delivered to the way_function() are not available to NextRelation() so its not possible to check if the way being processed is part of a multipolygon relation
I have tried Accept() on any suitably tagged relations, but it seems (to my eye) that any relations with type=="multipolygon" are not processed by the relation_scan_function().
So, the solution I am trying to find is to produce one polygon for each actual polygon, by preference from the individual tagged polygon (for a number of reasons individual features are preferable)
Any thoughts, suggestions, idea or help are appreciated.
PS as an aside, is there a Lua function in tilemaker
thatwill list all the tags available on a way/node/relation ?Apologies if this rambles a little, please feel free to ask for any clarification thats helpful
[EDIT]
As an example of another "problematic" relation see OSM Id:11894296
this is a multipolgon constituted of two linestring ways that comprise a single polygon (this would not be represented if i skip based on the type=="multipolygon" tag
Beta Was this translation helpful? Give feedback.
All reactions