Thank you Andy, I had a look at iD, I managed to build a polygon and will try to go further. I already had read the Area DataType problem description, but thanks. What I think is that we may need to invent a DataType that takes a definition from Boolean Set operators and polygons ( at least broken lines drawn by hand or curves converted to broken lines ).
For example a Coastline : - can be seen as intersection between a ground polygon and a sea polygon - can also be seen as a difference between a country border and its ground border An Object class taking two attributes : #include_polygons #exclude_polygons May be able to represent itself from those informations. It would make its persistence easier, in all Programming Languages. Clipper algorithm has been written in many languages. I guess Java, Python and C++ have libs to check if a way, a point, a node, belongs to such an area or to its border. I'd like to check if this problem has already been studied and is a dead end or if it has never been discussed or if it's a work in progress. I agree with you when you say it's not an algorithm problem, but will it be always the case? Either from persistence point of view or user interaction point of view. I also read the SVG explaining multi-polygon question and there's a polygon describing a hole in the area, so I wonder how we can avoid talking about Boolean operators here... Seems to me that it would help us not reinventing the wheel in geometry and building a versatile object class in any language that handle geometry libs. 2018-03-20 15:13 GMT+01:00 Andy Townsend <ajt1...@gmail.com>: > On 20/03/2018 12:57, Julien Cochennec wrote: > >> Hi, >> Newbie to OSM here, I'd like to contribute to the project, so I'm reading >> the ten priorities. >> Concerning the Data Type Area, I'd like to read any discussion about >> tools and structures in any languages especially about Boolean Set >> Operators (Union, Intersect, Difference, Xor), elementary way of building >> an area and use of Clipper Algorithm http://jsclipper.sourceforge.n >> et/6.4.2.2/main_demo.html ... >> > > The best description of the problem is probably the one at > https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Area_datatype . It's > not really an "algorithm" problem (at least not initially). > > What I'd suggest doing first is to become a bit more familiar with OSM, > and mapping your local area using the default "iD" editor is a great way to > start, because iD actually _does_ have a concept of areas, and interprets > OSM data as "area" or "non-area" as it goes along. > https://wiki.openstreetmap.org/wiki/Elements is also a good place to > start to see where OSM is now. > > Best Regards, > > Andy > > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev