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

Reply via email to