Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Frederik and all, Is there now a distinct description on the OSM Wiki, how polygons are defined in OSM? (e.g. self-intersections allowed? inner holes?) And: Outer boundaries seem to be encoded simply by the fact that first and last point have the same coordinates(?). But how are inner boundaries 'officially' encoded? -- S. 2008/3/17 Andy Robinson (blackadder) [EMAIL PROTECTED]: Andy Allan [mailto:[EMAIL PROTECTED] Sent: 17 March 2008 4:20 PM To: Andy Robinson (blackadder) Cc: Robert (Jamie) Munro; dev Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing On Mon, Mar 17, 2008 at 2:28 PM, Andy Robinson (blackadder) [EMAIL PROTECTED] wrote: Direction is important for one-way roads but shoudn't be for areas. Coastline is an understandable exception. And even that's easy for a user to swap around without realising the affect. Indeed. In reality though, since it's a wiki, when an error is spotted it gets corrected, so we could take the same view with areas, if it renders the wrong way around its going to get fixed pretty quickly. Hmm. If there's a 50/50 chance of any car-park doing a planet-span, I don't think we'll ever see the map again :-) I see your concern. A new user is probably going to find it a lot easier to understand that an area has to point in the clockwise direction than to have to add some complicated tagging to non closing areas to render properly, so for this approach I don't feel its too much to ask. Perhaps more complicated things will require more complicated rules, but I really think we should avoid requiring direction for non-directional features as much as possible. Inner/outer sounds much easier to understand to me than alternating directions, since the former is an intrinsic feature of the real-world object where the latter is just a consequence of our data model. For closed areas then it will always be possible to overrule if the rendering engine so decides. Which it'll have to do to avoid planet-spans. So if all renders *must* ignore way orientation for 3-node areas, then there's no right-hand-rule for this case at all and any claims to the contrary are a waste of time and energy to the mappers. Unless we want to be strict on our inputs (no planet-spanning areas permitted, so no anti-clockwise 3-node areas) and therefore overcomplicate the API, or make every editor and bulk-uploader strictly follow the convention, we may as well let the renders ignore the direction for this case. Again, perhaps it'll need to be more complicated for the more complex situations, but I want to nip in the bud any idea that basic areas must have a clockwise orientation. Agreed. I was more concerned with opening the ability to render more complex and larger areas like we deal with coastlines, but you are right, they should be special cases rather than the norm. Cheers Andy Cheers, Andy Cheers Andy Cheers, Andy It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 10:43 AM, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: Yes. That is what I am saying. 1 simple rule: *All* areas should be colour on the right (i.e. clockwise) No chance. This is a completely terrible idea. It makes it harder for newbies, who have to know to check and change the direction of the ways of an area, which is an entirely pointless process from their point of view and will probably make no sense to them. Direction is important for one-way roads but shoudn't be for areas. Coastline is an understandable exception. Cheers, Andy It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Robert Vollmert wrote: However, I believe it would be quite easy to make such a rule obvious to users, by attaching a few pixels of shading to the right of ways with area tags in the editors. I'm not sure that this would be at all easy to code (or quick to run) in Actionscript, sadly, or I'd have done it already for coastlines. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mar 17, 2008, at 13:33, Andy Allan wrote: On Fri, Mar 14, 2008 at 10:43 AM, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: Yes. That is what I am saying. 1 simple rule: *All* areas should be colour on the right (i.e. clockwise) No chance. This is a completely terrible idea. It makes it harder for newbies, who have to know to check and change the direction of the ways of an area, which is an entirely pointless process from their point of view and will probably make no sense to them. I agree that this is a bad idea. However, I believe it would be quite easy to make such a rule obvious to users, by attaching a few pixels of shading to the right of ways with area tags in the editors. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mon, Mar 17, 2008 at 2:28 PM, Andy Robinson (blackadder) [EMAIL PROTECTED] wrote: Direction is important for one-way roads but shoudn't be for areas. Coastline is an understandable exception. And even that's easy for a user to swap around without realising the affect. Indeed. In reality though, since it's a wiki, when an error is spotted it gets corrected, so we could take the same view with areas, if it renders the wrong way around its going to get fixed pretty quickly. Hmm. If there's a 50/50 chance of any car-park doing a planet-span, I don't think we'll ever see the map again :-) A new user is probably going to find it a lot easier to understand that an area has to point in the clockwise direction than to have to add some complicated tagging to non closing areas to render properly, so for this approach I don't feel its too much to ask. Perhaps more complicated things will require more complicated rules, but I really think we should avoid requiring direction for non-directional features as much as possible. Inner/outer sounds much easier to understand to me than alternating directions, since the former is an intrinsic feature of the real-world object where the latter is just a consequence of our data model. For closed areas then it will always be possible to overrule if the rendering engine so decides. Which it'll have to do to avoid planet-spans. So if all renders *must* ignore way orientation for 3-node areas, then there's no right-hand-rule for this case at all and any claims to the contrary are a waste of time and energy to the mappers. Unless we want to be strict on our inputs (no planet-spanning areas permitted, so no anti-clockwise 3-node areas) and therefore overcomplicate the API, or make every editor and bulk-uploader strictly follow the convention, we may as well let the renders ignore the direction for this case. Again, perhaps it'll need to be more complicated for the more complex situations, but I want to nip in the bud any idea that basic areas must have a clockwise orientation. Cheers, Andy Cheers Andy Cheers, Andy It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Andy Allan [mailto:[EMAIL PROTECTED] Sent: 17 March 2008 4:20 PM To: Andy Robinson (blackadder) Cc: Robert (Jamie) Munro; dev Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing On Mon, Mar 17, 2008 at 2:28 PM, Andy Robinson (blackadder) [EMAIL PROTECTED] wrote: Direction is important for one-way roads but shoudn't be for areas. Coastline is an understandable exception. And even that's easy for a user to swap around without realising the affect. Indeed. In reality though, since it's a wiki, when an error is spotted it gets corrected, so we could take the same view with areas, if it renders the wrong way around its going to get fixed pretty quickly. Hmm. If there's a 50/50 chance of any car-park doing a planet-span, I don't think we'll ever see the map again :-) I see your concern. A new user is probably going to find it a lot easier to understand that an area has to point in the clockwise direction than to have to add some complicated tagging to non closing areas to render properly, so for this approach I don't feel its too much to ask. Perhaps more complicated things will require more complicated rules, but I really think we should avoid requiring direction for non-directional features as much as possible. Inner/outer sounds much easier to understand to me than alternating directions, since the former is an intrinsic feature of the real-world object where the latter is just a consequence of our data model. For closed areas then it will always be possible to overrule if the rendering engine so decides. Which it'll have to do to avoid planet-spans. So if all renders *must* ignore way orientation for 3-node areas, then there's no right-hand-rule for this case at all and any claims to the contrary are a waste of time and energy to the mappers. Unless we want to be strict on our inputs (no planet-spanning areas permitted, so no anti-clockwise 3-node areas) and therefore overcomplicate the API, or make every editor and bulk-uploader strictly follow the convention, we may as well let the renders ignore the direction for this case. Again, perhaps it'll need to be more complicated for the more complex situations, but I want to nip in the bud any idea that basic areas must have a clockwise orientation. Agreed. I was more concerned with opening the ability to render more complex and larger areas like we deal with coastlines, but you are right, they should be special cases rather than the norm. Cheers Andy Cheers, Andy Cheers Andy Cheers, Andy It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 03:32:45PM +, 80n wrote: Sometimes this is unavoidable. Consider a commercial area (landuse=commercial) surrounded by a residential area (landuse=residential). It's not possible to create a single way that can be used as the boundary for both these features as they would both need to specify different values for the landuse tag. That is why you use a relation containing the inner and outer boundary to represent the residential area. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
What we need is some decent test data. http://www.elbruz.org/islands/Islands%20and%20Lakes.htm Anyone fancy a mapping party in Luzon? 80n On Fri, Mar 14, 2008 at 6:45 AM, bvh [EMAIL PROTECTED] wrote: On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mar 14, 2008, at 00:05, Frederik Ramm wrote: I'm currently working on a Perl re-implementation of Osmarender. It is already almost feature complete; I've made an early announcement on the [EMAIL PROTECTED] list: Great! change is the way polygons with holes are drawn. I want to switch from the default evenodd rule (that relies on the directions of ways) to the nonzero rule, and use it like so (pseudo code, omitting all the filtering and layering stuff): for each way with area tagging if way is member of multipoly relation if role is inner ignore way I agree with Cartinus here -- inner ways should be rendered as usual. You could ignore tags on the inner way that are also on the outer way as suggested. Ultimately, I think this should not be necessary. It is straightforward to remove these duplicate tags once. Do you think this would work? I'm a bit unsure about ignoring the tags on the relation; ideally these should override tags on the outer way, if specified (or no?). But since nobody supports that anyway at the moment, I thought we can leave that for later. I think it depends on how you view the relation. 1. The area is the relation, inner and outer ways are just borders. 2. The area is the outer way, which has holes as described by the relation. I tend towards the second, which implies tags on the outer way. It has the advantage of generalizing normal areas directly. If tags were to go on the relation, adding a hole to an area would require moving the tags from the way to the relation. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mar 14, 2008, at 10:01, Andy Robinson ((blackadder)) wrote: If I've got this all wrong then someone point me to better understand the problem. Small point: This is also about, say, clearings in forests and cemeteries in parks. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
I'll admit and apologise that I haven't been following this thread too closely, but from skimming over the surface wanted to make a couple of observations. The way we currently draw coastlines, as a boundary between the landmass and a body of water sitting within the landmass is no different from the position with lakes. If we think of the world as essentially a solid land and that we have seas, oceans and lakes suck into it we can perhaps remove some of the complexity of what is being discussed. If we were to say that the boundary between land and a water body, regardless of type, was to be treated in the same way that we now treat coastlines, would we not have a straightforward method of tagging for everything? That leaves the issue of rendering order so that land that pokes through an enveloping body of water gets rendered last. Surely the layer facility deals with that? I appreciate that some will wish to associate all the different edges of a water body (outer and multiple inners), but we have relations for that. If I've got this all wrong then someone point me to better understand the problem. Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 80n Sent: 14 March 2008 8:49 AM To: dev@openstreetmap.org Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing What we need is some decent test data. http://www.elbruz.org/islands/Islands%20and%20Lakes.htm Anyone fancy a mapping party in Luzon? 80n On Fri, Mar 14, 2008 at 6:45 AM, bvh [EMAIL PROTECTED] wrote: On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik Ramm wrote: | Hi, | | I think we should stick with the evenodd rule. It is not that difficult | for users when editing - colour on the right, it is neccesary for | coastlines, and there is nothing to gain by making it unneccesary. If | some renderers don't need the rule, it's going to be much harder to tell | people they are wrong when the draw things the wrong way round. | | The logical consequence of your above statement would be that we | should drop rendering of simple areas (without holes) unless they're | drawn clockwise! Yes. That is what I am saying. 1 simple rule: *All* areas should be colour on the right (i.e. clockwise) It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 11:39 AM, bvh [EMAIL PROTECTED] wrote: I disagree. Requiring mappers to add two ways that overlap completly is with the goal of making the math simpler is shifting the burden from software to users. On Mar 14, 2008, at 16:32, 80n wrote: Sometimes this is unavoidable. Consider a commercial area (landuse=commercial) surrounded by a residential area (landuse=residential). It's not possible to create a single way that can be used as the boundary for both these features as they would both need to specify different values for the landuse tag. There's no need to put a landuse=residential on the way surrounding the commercial area. Putting tags on the outer way suffices. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Jon Burgess wrote: From a pure design perspective the cleanest approach would be (IMO) to have the tags only on the relation. Otherwise there is always the possibility for ambiguity in cases where the tags on the outer ways differ. Yes this is an error, but one which is bound to occur occasionally. It also enables other use cases like re-using a way along a border between 2 country polygons. But then we'll end up with non-tagged ways. From the OSM data design perspective its not going to be very practical for someone to determine whether the way is not tagged because it belongs to a certain relation or because it was forgotten. And don't forget that a relation could be anything. not just polygon-with-hole, so you would have to understand the semantics of all types of relations. Also, since AFAIK osmxapi currently does not support relations, renderers which use data collected from it would have to ignore these untagged ways completely. Igor -- http://igorbrejc.net ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Hi, I think we should stick with the evenodd rule. It is not that difficult for users when editing - colour on the right, it is neccesary for coastlines, and there is nothing to gain by making it unneccesary. If some renderers don't need the rule, it's going to be much harder to tell people they are wrong when the draw things the wrong way round. I think coastlines are really a big exception and everybody can understand that. If we have proper inner and outer roles, direction of the ways is not required for computing and simply requiring it to make people into better coastline mappers seems a bit over the top to me. The logical consequence of your above statement would be that we should drop rendering of simple areas (without holes) unless they're drawn clockwise! Also, my idea would allow a way to serve as an inner member of one multipoly at the same time as as an outer member of another; I think you couldn't get that with evenodd. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Hi, Do you think this would work? I'm a bit unsure about ignoring the tags on the relation; ideally these should override tags on the outer way, if specified (or no?). But since nobody supports that anyway at the moment, I thought we can leave that for later. Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Thu, Mar 13, 2008 at 6:15 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, If I understand this correctly, then for a forested island in a lake you'd need to have the island twice in the osm data. Once for the hole in the lake and once for the forest on the island. No. Assuming for a moment that you really wanted to model the forest as a hole in the island, which doesn't make a lot of sense to me since I don't generally map forests as holes in the country, but I understand it's only a example, then the island would be there only once, be part of two relations, one where it would play the outer role to the forest and one where it would play the inner role to the lake. Bye Frederik I don't think he means a hole in the island. The island itself is just a simple, single polygon. I think his question is: Can the way which represents the island also be tagged with a forest which covers the entire island? In your original pseudocode, the forest bit would be ignored because only the lake tags would count. I don't see why you'd want to create yet another multipolygon relation with only one role (an outer) as you've described. Karl ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
