<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Thank you Andy, I had a look at iD, I managed to build a polygon and will try to go further.<br></div><div>I already had read the Area DataType problem description, but thanks.<br></div>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 ).<br><br></div>For example a Coastline :<br></div>- can be seen as intersection between a ground polygon and a sea polygon<br></div>- can also be seen as a difference between a country border and its ground border<br></div>An Object class taking two attributes :<br></div>#include_polygons<br></div>#exclude_polygons<br></div>May be able to represent itself from those informations.<br></div>It would make its persistence easier, in all Programming Languages.<br></div>Clipper algorithm has been written in many languages.<br></div>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.<br></div>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.<br><br></div>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.<br></div>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... <br><div><div><div><div><div><div>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.<br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-20 15:13 GMT+01:00 Andy Townsend <span dir="ltr"><<a href="mailto:ajt1047@gmail.com" target="_blank">ajt1047@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20/03/2018 12:57, Julien Cochennec wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
Newbie to OSM here, I'd like to contribute to the project, so I'm reading the ten priorities.<br>
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 <a href="http://jsclipper.sourceforge.net/6.4.2.2/main_demo.html" rel="noreferrer" target="_blank">http://jsclipper.sourceforge.n<wbr>et/6.4.2.2/main_demo.html</a> ...<br>
</blockquote>
<br></span>
The best description of the problem is probably the one at <a href="https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Area_datatype" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Top_Ten_Tasks#Area_datat<wbr>ype</a> . It's not really an "algorithm" problem (at least not initially).<br>
<br>
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.  <a href="https://wiki.openstreetmap.org/wiki/Elements" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Elements</a> is also a good place to start to see where OSM is now.<br>
<br>
Best Regards,<br>
<br>
Andy<br>
<br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org" target="_blank">dev@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/dev</a><br>
</blockquote></div><br></div>