This document discusses problems with how polygons are represented in OpenStreetMap and proposes a new area datatype to address these issues. Specifically, it notes that there are currently multiple ways to define polygons that make them difficult to understand, edit, and use. The proposed area datatype would provide a single representation for polygons and make them easier to validate and work with programmatically. It outlines high-level considerations for what such a datatype might look like and how existing polygon data could be migrated to the new format.

1. Towards an Area Datatype
for OSM
Jochen
Topf

2. Fundamental Geometry Types

3. Point
Linestring
Polygon

4. Point
Node
Linestring
Way
Polygon
??

5. Polygon with Holes
1 outer ring, 2 inner rings

6. Multipolygon
2 outer rings, 2 inner rings

7. Definition
A polygon
devides
the surface of the planet
into
two regions:
inside - outside

8. Definition
A polygon is usually described by its border.
The border is a bunch of lines that never intersect.
Border line direction?

9. Definition
A polygon is usually described by its border.
The border is a bunch of lines that never intersect.
Border line direction?

10. Polygons in OSM:
There Is More Than One Way
To Do It!

11. Polygon Type #1:
Closed way

12. Polygon Type #1:
Closed way
No holes
Depends on tags...

13. Polygon Type #1:
Closed way
highway=residential
natural=wood
Linestring or polygon or maybe both...

14. Polygon Type #1:
area=yes
highway=pedestrian
highway=pedestrian
area=yes

15. Polygon Type #2:
Multipolygon Relation
type=multipolygon

16. Polygon Type #2:
Multipolygon Relation
type=multipolygon
Can have multiple inner and outer rings.

17. Polygon Type #3:
Boundary Relation
type=boundary

18. Polygon Type #3:
Boundary Relation
Role: subarea !
type=boundary

19. Polygon Type #4:
Coastline
Ways connected end-to-end.
Land always on left, water always on right.

20. Polygon Type #5:
Riverbank
waterway=riverbank

21. Polygon Type #5:
Riverbank
waterway=riverbank

22. Polygon Type #5:
Riverbank
waterway=riverbank

23. Types of Polygons
#1 Closed Ways
#2 Multipolygon Relation
#3 Boundary Relation
#4 Coastlines
#5 Riverbanks

24. Problems
Which polygon type to use?
(lakes?, rivers?, boundaries?)
What if several types
are in use at the same time?
Converting from one to another?

26. Problems with
Multipolygon Relations
Tags on relation + outer ways + inner ways
Broken geometries (Self-intersections, ...)
Inner/outer mixups
Subareas

27. Broken Multipolygon Relations
About 2% broken, another 2% warnings

28. Polygons in OSM are...
difficult to understand,
diffcult to edit,
difficult to use.

29. Some Numbers...
110 million (closed way) polygons
90 million are buildings
72 million have 6 points or less
900,000 area=yes
750,000 natural=coastline (31 million nodes)
260,000 waterway=riverbank

30. Relations
1,000,000 type=multipolygon
200,000 type=boundary
For together >2 million (multi-)polygons
1,100,000 landuse/natural=*
240,000 boundary=administrative
Largest multipolygon 300,000 points

31. What are we going to do about it?

32. A New
Area
Datatype

33. What Should it Look Like?
Referencing nodes? (Like a way?)
(What about huge areas?)
Referencing ways? (A bit like MP relations?)
(What about small areas?)
Not referencing anything, coordinates inside?
(Like Simple Feature)

34. Polygons are Problematic...
1. Because there are several ways to accomplish
the same thing.
2. Because they are hard to edit and keep valid.

35. Polygons are Problematic...
1. Because there are several ways to accomplish
the same thing.
→ One area datatype
2. Because they are hard to edit and keep valid.

36. Polygons are Problematic...
1. Because there are several ways to accomplish
the same thing.
→ One area datatype
2. Because they are hard to edit and keep valid.
→ Let the computer do the checking

37. Validation
In the editor
On the server
Partial download
Lightweight!?
Check locally
Check only
changes!

38. API
Full download of areas not always possible!
Download parts of areas in bbox
+
Upload changes of areas in bbox

39. I think this is doable!

40. *Details are left
as an exercise
for the reader.

41. Migration
1. Add support for new area type
2. Convert some areas automatically
3. Convert rest manually
4. Remove support for old areas

42. Thanks!
http://wiki.osm.org/wiki/The_Future_of_Areas
Jochen Topf
jochen@topf.org
jochentopf.com