Re: [OSM-talk] multipolygon (lake) not rendering
On Mon, Oct 26, 2009 at 10:30 AM, Frederik Ramm wrote: > The other is multipolygons, where we (ab)use the relation object which is > *normally* used to model a relation between several primitives, to actually > construct a primitive in the first place. Constructing the geo-object and > putting it in relation to other objects should really happen on separate > layers. Hmm...that's interesting. I don't like adding tables when it's not necessary, as it tends to introduce ambiguities... But how about an "object" table, which would have the same fields as the relation tables plus a field "object_type". Ways would all be converted to objects with nodes as members (and member_type "node"). Open ways would become objects with type "linestring". Closed ways could have type "polygon" or type "area" depending whether it's supposed to be filled or unfilled. Relations could have type "relation". Integrity checking would ensure that the type matches the data (e.g. polygons/areas must be closed). New objects can be invented without altering the table structure (preferably this ability would still require administrator intervention, though - I don't like the idea of casual editors inventing their own object_types willy nilly). Current: way_nodes, way_tags, ways, relation_members, relation_tags, relations. Proposed: object_members, object_tags, objects > I would also hope that along with a proper area data concept would come the > ability of the API to return an area to the caller even if the area fully > encompasses the queried bounding box. That's basically just an index issue. Now that the database is on Postgresql, updating it to use postgis features will probably go a long way. Some sort of tile-based caching would probably help too. If it's still too much strain on the main database, a read-only cache which potentially lags the live data could definitely do it. As it is, the API wont even return a way which passes through a bounding box, if none of its nodes are located within the bounding box. It's not a schema problem so much as a performance/indexing problem. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Hi, Anthony wrote: > What would be the advantage of an area data type? Would this be a > separate table or just a type of relation? Exactly what advantage(s) it has of course depends on how it is designed and implemented in the end. The problem with our current approach is that we are mixing layers in our model in at least two places. One, completely apart from multipolygons, is the way we use a closed way to model a polygon - or not (closed way with natural=forest ==> polygon, closed way with junction=roundabout ==> linear ring). This means that it is impossible to "blindly" convert our data into, say, a shape file; you have to actually look at the tags and understand them to do this, even if you didn't actually want to meddle with tags. This is as if you asked someone to transfer an old VHS tape to DVD and they say: But I can't to that without knowing what kind of film you have on there! (Well ok, lame comparison, but you get the drift.) The other is multipolygons, where we (ab)use the relation object which is *normally* used to model a relation between several primitives, to actually construct a primitive in the first place. Constructing the geo-object and putting it in relation to other objects should really happen on separate layers. I would also hope that along with a proper area data concept would come the ability of the API to return an area to the caller even if the area fully encompasses the queried bounding box. All these are not big things and we have meddled our way through and around them, but I'm beginning to think that there are places where you can and should discard ancient wisdom because it only slows your progress - and others were, even if it is not clear to you from the outset, actually referring to that ancient wisdom makes things easier. Computational geometry has worked with point, line, and polygon primitives for ever, and maybe computational geometry is one of the latter sorts of ancient wisdom. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Mon, Oct 26, 2009 at 9:53 AM, Frederik Ramm wrote: > Anthony wrote: >> Do advanced multipolygons have to have an inner? > > No. Great. > Personally, I am hoping that we will (re)introduce a proper area data type > some day because even though the multipolygons were a good idea at the time, > they do seem a bit clumsy now. What would be the advantage of an area data type? Would this be a separate table or just a type of relation? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Frederik Ramm wrote: > Personally, I am hoping that we will (re)introduce a proper > area data type some day because even though the multipolygons > were a good idea at the time, they do seem a bit clumsy now. I agree. Areas will come ever more complicated with data imports and tracing from high resolution images. I checked that the biggest lake polygon in the official Finnish mapping data has 287273 vertices, 5484 islands and the total length of this simple polygon is more that 5276 kilometers. It would be quite a beast as OSM multipolygon relation. -Jukka- > Bye > Frederik > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Hi, Anthony wrote: >> A further problem arises when the hole boundary consists of multiple >> ways, something that is allowed for advanced multipolygons, but you >> would not be able to place the name of the island (or whatever) in this >> scenario. > > You could if you used a second multipolygon with the "hole" ways as > the outer, right? That is correct. > Do advanced multipolygons have to have an inner? No. > If so you could always use a boundary relation. Yes; a boundary relation is just an advanced multipolygon by another name. People have even suggested to drop the relation type "boundary" altogether and name these "multipolygon" as well (the fact that it is a boundary can be seen from the bondary=something tag anyway). Personally, I am hoping that we will (re)introduce a proper area data type some day because even though the multipolygons were a good idea at the time, they do seem a bit clumsy now. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Mon, Oct 26, 2009 at 5:24 AM, Frederik Ramm wrote: > A further problem arises when the hole boundary consists of multiple > ways, something that is allowed for advanced multipolygons, but you > would not be able to place the name of the island (or whatever) in this > scenario. You could if you used a second multipolygon with the "hole" ways as the outer, right? Do advanced multipolygons have to have an inner? If so you could always use a boundary relation. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Hi, Rahkonen Jukka wrote: > I meant "Do all the polygon parts get their correct names in > rendering, There are multiple renderers and they generally don't agree on how to handle multipolygons. I would assume that most can deal with a hole of a multipolygon having its own identity (e.g. hole in forest tagged as farm). Most will probably not be able to derive the identity of something from the kind of polygon surrounding it - i.e. you will probably have to tag an island as such, and not count on the renderer knowing that everything that is a hole in a water polygon will automatically be an island. There is also a problem with touching holes; if you have a forest and in the forest there is a farm and a lake next to each other, then some people draw a forest with two holes, whereas standard simple feature geometry does not allow touching holes (and anyway, as you correctly say, for export e.g. in shapefiles, extra polygons would have to be created for the holes). A further problem arises when the hole boundary consists of multiple ways, something that is allowed for advanced multipolygons, but you would not be able to place the name of the island (or whatever) in this scenario. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Hi, I meant "Do all the polygon parts get their correct names in rendering, that is, lake the name given for the outer ring and each islands the name given for the inner ring". Maybe also "Can export utilities make a correct output of a lake polygon as a polygon with holes and islands as separate polygons for non-OSM programs which cannot handle polygon holes as separate features". I believe that for example PostGIS used for Mapnik rendering belongs to those non-OSM programs which might have troubles with inner rings having just a name tag. -Jukka Rahkonen- John F. Eldredge wrote: > I think he means, "Wouldn't it be better to tag the entire island with a > name, rather than tagging each segment separately?" > -Original Message- From: Frederik Ramm Date: Sun, 25 Oct 2009 23:49:16 To: Rahkonen Jukka Cc: Subject: Re: [OSM-talk] multipolygon (lake) not rendering > Hi, > Rahkonen Jukka wrote: > >> For what? The inner ways of multipolygons where the outer way is >> tagged as natural=water? You don't need to tag them with anything >> indicating that they're an island, they already are tagged as islands >> implicitly since they're a multipolygon. > > Islands tend to have names. Does it really work to give a name for each inner > ring of a lake polygon without any other tags? > What do you mean by "does it really work"? > Bye > Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
I think he means, "Wouldn't it be better to tag the entire island with a name, rather than tagging each segment separately?" -- John F. Eldredge -- j...@jfeldredge.com "Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria -Original Message- From: Frederik Ramm Date: Sun, 25 Oct 2009 23:49:16 To: Rahkonen Jukka Cc: Subject: Re: [OSM-talk] multipolygon (lake) not rendering Hi, Rahkonen Jukka wrote: >> For what? The inner ways of multipolygons where the outer way is >> tagged as natural=water? You don't need to tag them with anything >> indicating that they're an island, they already are tagged as islands >> implicitly since they're a multipolygon. > > Islands tend to have names. Does it really work to give a name for each inner > ring of a lake polygon without any other tags? What do you mean by "does it really work"? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Hi, Rahkonen Jukka wrote: >> For what? The inner ways of multipolygons where the outer way is >> tagged as natural=water? You don't need to tag them with anything >> indicating that they're an island, they already are tagged as islands >> implicitly since they're a multipolygon. > > Islands tend to have names. Does it really work to give a name for each inner > ring of a lake polygon without any other tags? What do you mean by "does it really work"? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Ævar Arnfjörð Bjarmason gmail.com> writes: > mmmtike.fi> wrote: > > Could it be possible to have a tagging rule that would be usable for all > > islands? Island is always an island and it is also always dry land (I > > suppose) > > but all islands are not natural=wood. Would using place=island or > > place=islet be > > a good alternative? > > For what? The inner ways of multipolygons where the outer way is > tagged as natural=water? You don't need to tag them with anything > indicating that they're an island, they already are tagged as islands > implicitly since they're a multipolygon. Islands tend to have names. Does it really work to give a name for each inner ring of a lake polygon without any other tags? -Jukka- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Sun, Oct 25, 2009 at 10:37 AM, Jukka Rahkonen wrote: > Jon Burgess googlemail.com> writes: > >> >> On Sat, 2009-10-24 at 13:41 +0200, Peter Herison wrote: > >> > But if the inner member is also an island? Eventually the island is also >> > covered with wood? How to tag the inner way in this case? >> >> In that case tag the inner way with natural=wood. > > Could it be possible to have a tagging rule that would be usable for all > islands? Island is always an island and it is also always dry land (I suppose) > but all islands are not natural=wood. Would using place=island or place=islet > be > a good alternative? For what? The inner ways of multipolygons where the outer way is tagged as natural=water? You don't need to tag them with anything indicating that they're an island, they already are tagged as islands implicitly since they're a multipolygon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Jon Burgess googlemail.com> writes: > > On Sat, 2009-10-24 at 13:41 +0200, Peter Herison wrote: > > But if the inner member is also an island? Eventually the island is also > > covered with wood? How to tag the inner way in this case? > > In that case tag the inner way with natural=wood. Could it be possible to have a tagging rule that would be usable for all islands? Island is always an island and it is also always dry land (I suppose) but all islands are not natural=wood. Would using place=island or place=islet be a good alternative? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
I think you mean natural=water - natural=lake is undocumented ;-) I'd understand natural=lakeshore - but that's undocumented too Roman > Date: Sat, 24 Oct 2009 11:07:59 + > From: ?var Arnfj?r? Bjarmason > Subject: Re: [OSM-talk] multipolygon (lake) not rendering > To: Peter Herison > Cc: talk@openstreetmap.org > Message-ID: > <51dd1af80910240407h292c83ebjdbcd127e6e187...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > On Sat, Oct 24, 2009 at 9:54 AM, Peter Herison wrote: >> Could somebody take a look at >> http://www.openstreetmap.org/browse/relation/300524 and why it's not >> rendering in mapnik? >> >> There are also some issues with osmarender: >> http://www.openstreetmap.org/?lat=29.5216&lon=-101.0699&zoom=12&layers=0B00FTF > I've fixed it: http://www.openstreetmap.org/browse/changeset/2936060 > * You need to add natural=lake on the relation when outer is made up > of multiple ways > * Don't add tags on the inner ways. That's redundant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Sat, 2009-10-24 at 13:41 +0200, Peter Herison wrote: > Ævar Arnfjörð Bjarmason schrieb: > > Peter Herison wrote: > >> Could somebody take a look at > >> http://www.openstreetmap.org/browse/relation/300524 and why it's > >> not rendering in mapnik? > >> There are also some issues with osmarender: > >> http://www.openstreetmap.org/?lat=29.5216&lon=-101.0699&zoom=12&layers=0B00FTF > > > > I've fixed it: http://www.openstreetmap.org/browse/changeset/2936060 > > > > * You need to add natural=lake on the relation when outer is made up > > of multiple ways > > *Dough* Thanks :) > > > * Don't add tags on the inner ways. That's redundant > > But if the inner member is also an island? Eventually the island is also > covered with wood? How to tag the inner way in this case? In that case tag the inner way with natural=wood. The confusing and redundant thing is to tag the inner ways with natural=water or natural=land. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
Ævar Arnfjörð Bjarmason schrieb: > Peter Herison wrote: >> Could somebody take a look at >> http://www.openstreetmap.org/browse/relation/300524 and why it's >> not rendering in mapnik? >> There are also some issues with osmarender: >> http://www.openstreetmap.org/?lat=29.5216&lon=-101.0699&zoom=12&layers=0B00FTF > > I've fixed it: http://www.openstreetmap.org/browse/changeset/2936060 > > * You need to add natural=lake on the relation when outer is made up > of multiple ways *Dough* Thanks :) > * Don't add tags on the inner ways. That's redundant But if the inner member is also an island? Eventually the island is also covered with wood? How to tag the inner way in this case? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Sat, Oct 24, 2009 at 9:54 AM, Peter Herison wrote: > Could somebody take a look at > http://www.openstreetmap.org/browse/relation/300524 and why it's not > rendering in mapnik? > > There are also some issues with osmarender: > http://www.openstreetmap.org/?lat=29.5216&lon=-101.0699&zoom=12&layers=0B00FTF I've fixed it: http://www.openstreetmap.org/browse/changeset/2936060 * You need to add natural=lake on the relation when outer is made up of multiple ways * Don't add tags on the inner ways. That's redundant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] multipolygon (lake) not rendering
Could somebody take a look at http://www.openstreetmap.org/browse/relation/300524 and why it's not rendering in mapnik? There are also some issues with osmarender: http://www.openstreetmap.org/?lat=29.5216&lon=-101.0699&zoom=12&layers=0B00FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
