Re: [OSM-dev] Call for A Proper Area Datatype for OSM
Am 10.02.2013 21:57, schrieb sly (sylvain letuffe): Le dimanche 10 février 2013 21:31:28, Jochen Topf a écrit : Actually the transition is the easy part. I am uneasy with your use of the work easy ! What will be the harder part ! "Just add support in every editors, most data consumer tools and export/api side, update the api so you don't download all coastlines at once, run a script for converting while keeping history intact, still allowing reverts" is what you would call easy ? I admire your enthusiasm ;-) Fortunately it should be easy 1) to keep some kind of backward compatibility: 1.a. download from the api: The API could e.g. support a compatibility switch that forces returning the new areas as the old ways with an additional "area=yes"-Tag. area=yes is in fact already used for stating that this feature should be interpreted as an area. Without that switch the areas could be produced as the new area-objects/tags. 1.b. upload to the api: For compatibility here the area=yes could be some standard tag for "this is an area", which could trigger the api to check if it's possible to create an area out of the way or not, and do so if it's possible. 2) to enhance editors: 2.a. JOSM: already supports area styling at least; it should not be that difficult to introduce the area object as a fourth primitive. 2.b. P2: as far as I know P2 has area support in the sense that areas are dealt with differently in code. 2.c. iD definitively handles areas differently already. 2.d: other editors shouldn't be much harder, I would guess - and if it takes time, see (1) above. ...provided that (as you mentioned already)... 3) ...the problem of really big areas is solved: Downloading the whole coastline of Australia is far too much for many editors, the API and often for the main memory is an sometimes impossible challenge. But that probably has to be solved nevertheless, and if, I believe, we could find a compatible solution again. One idea that comes to my mind might be to allow downloading "area-extracts" (as well as way-extracts). This could be done similar to what we have for relations already: Relations often are not completely downloaded in josm, and the relation editor deals well with that issue. For ways something similar could be done: Load way X in bbox B would lead to all nodes in B (and the next one outside) as "real nodes" as well as "pseudo nodes" to provide an estimated area around. Editors could use the result for drawing the polygon as usual (and for the first time they would succeed in filling areas correctly even if not loaded completely, where they fail for multi-outer-mp-relations yet), and the API could accept something like incomplete-edit-calls for areas, like "edit way X: old node index range [3..123] out of version 7 changes to the use of nodes [...] (might be less nodes, more nodes or the same node count, but the first two nodes keep unchanged, and the nodes behind index 123 doesn't change either)". Even more than one node range could be manipulated this way. I know: there are more issues, even with this short sketch of an idea (like e.g. "locking" (you usually can only edit an osm object nobody edited since you downloaded it)), but I'm sure it's possible to solve these as well. regards Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Call for A Proper Area Datatype for OSM
Le dimanche 10 février 2013 21:31:28, Jochen Topf a écrit : > Actually the transition is the easy part. I am uneasy with your use of the work easy ! What will be the harder part ! "Just add support in every editors, most data consumer tools and export/api side, update the api so you don't download all coastlines at once, run a script for converting while keeping history intact, still allowing reverts" is what you would call easy ? I admire your enthusiasm ;-) Maybe I would call it "the maybe easier part" ;-) Still, your blog entry is a really good introduction to problems anticipation, I just find it really optimistic, and I would bet that the "discussion part about what model to choose" would be, if not faster, at least much less risky for the contributors discovering their version of software X suddenly broke without warning... -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Call for A Proper Area Datatype for OSM
On Sun, Feb 10, 2013 at 11:03:43AM -0500, Serge Wroclawski wrote: > I think many people in the community would be in favor of an area element. > > But "Show us the code", in particular, how would a transition work? Actually the transition is the easy part. Just add support for new area data type to all software but keep old code around. Then when everything is tested, have a script run through the database and create new area objects for all existing objects that look like areas and remove the original object. Leave everything that can't be converted automatically for a human to convert. The difficult part is figuring out how the area datatype is supposed to look. See http://wiki.openstreetmap.org/wiki/The_Future_of_Areas Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Call for A Proper Area Datatype for OSM
Serge Wroclawski schrieb am 10.02.2013 17:03: > I think many people in the community would be in favor of an area element. > But "Show us the code", in particular, how would a transition work? please read http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html It has an paragraph named "Migration". -- greetings Holger ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Call for A Proper Area Datatype for OSM
I think many people in the community would be in favor of an area element. But "Show us the code", in particular, how would a transition work? - Serge ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Call for A Proper Area Datatype for OSM
Hi Roland 2013/2/10 Roland Olbricht : > ... > What makes me hesitate about GeoJSON is essentially that there is no clear > rule whether an elements becomes a linestring or a polygon. Solving this will > require both a test for validness (e.g. self intersections, but also some > other corner cases. Most are listed on > http://wiki.openstreetmap.org/wiki/Multipolygon#Valid_Multipolygon_conditions > ) as well as a semantic interpretation of tags. > > The most likely mid-term solution is to convert ways always to linestrings, > but the area type to polygons. This has the advantage that both the code to > validate polygons and the choice of tags is done by code that does this anyway > for area creation. > > I will code this proper together with a area output implementation conforming > to Jochen's outline > http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html > so it will take some time until it gets available. I expect it is complete > some weeks before the FOSSGIS conference, together with a couple of other > larger changes. I understand and I know very well about the current unsatisfying situation in OSM. When we implemented OSM-in-a-box prototype this part of code took most of the time fiddling around about if a way was meant as linstring or polygon. And I'm convinced that an area type on its own would make live easier not only for coders but also for mappers who will get more clear rules about what is an area. This is why I am proposing an area/polygon type in OSM since years. And I'm fully supporting Jochen's proposal. (Note: What OSM calls a Multipolygon is in fact simply a polygon (containing zero to many inner boundaries) in OGC/ISO/Geoscience. This would'nt be a problem unless because of OGC/ISO/Geoscience defines Multpolygon as a SET OF (ogc-)polygons). To be more specific regarding the corner cases, Martin mentioned two of them: "E.g. one can interpret an administrative boundary as a border line [LineString] or the containing area [Polygon]. It gets even more non-trivial for some of the more abstract relation types (turn restrictions, enforcements, etc.)." To me the geometry type of such admin. boundaries is always a polygon. This is not an interpretation issue about how to model and store it, but rather a question of handling in some applications (e.g. after clipping). Regarding turn restrictions: I suppose he refers to the fact that they are encoded with linestrings. But here we ware discussing basic geometry types, not higher level semantics. Yours, Stefan 2013/2/10 Roland Olbricht : > Hello Stefan, > >> That's what I conclude from [1] i.e. ... >> > > The format option "JSON" meets the format described here: > http://wiki.openstreetmap.org/wiki/Xappy.js > > This has exactly the same semantics like OSM XML and only different syntax. > However, JSON makes some JavaScript applications a lot easier than XML, so I > followed the suggestion to add it. > > What makes me hesitate about GeoJSON is essentially that there is no clear > rule whether an elements becomes a linestring or a polygon. Solving this will > require both a test for validness (e.g. self intersections, but also some > other corner cases. Most are listed on > http://wiki.openstreetmap.org/wiki/Multipolygon#Valid_Multipolygon_conditions > ) as well as a semantic interpretation of tags. > > The most likely mid-term solution is to convert ways always to linestrings, > but the area type to polygons. This has the advantage that both the code to > validate polygons and the choice of tags is done by code that does this anyway > for area creation. > > I will code this proper together with a area output implementation conforming > to Jochen's outline > http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html > so it will take some time until it gets available. I expect it is complete > some weeks before the FOSSGIS conference, together with a couple of other > larger changes. > > Cheers, > > Roland > > > ___ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
