Open JanJakes opened 8 years ago
I agree. ogr2ogr has a function based on keys to tell, which elements should be converted to polygons, but key-only isn't enought.
It would be great to give a list of key/value combinations, f.e. for "highway=platform" when some missed out "area=yes".
Right now, I'm doing pre-processing to my OSM files and add "area=yes" to all t he key/value-combinations, which should be polygons :)
Have you tried type_mappings
? https://github.com/omniscale/imposm3/blob/master/test/single_table_mapping.json#L30...L43
Yeah, but that doesn't help with mappings like amenity: [__any__]
or toursim: [__any__]
.
This should be resolved with the new area handling. https://imposm.org/docs/imposm3/latest/mapping.html#areas Can you check that?
We've tried that but it unfortunately doesn't solve our use case. The problem is that area_tags
/linear_tags
are applied only on tables of type linestring
/polygon
(here and here) but we put everything to a single geometry
table (with use_single_id_space: true
).
Maybe changing the condition on line 294 from TableType(t.Type) == LineStringTable
to (TableType(t.Type) == LineStringTable || TableType(t.Type) == GeometryTable)
and similarly for line 310 could solve the problem?
When using mappings like
amenity: [__any__]
withuse_single_id_space
and typegeometry
I get many items twice - once with polygon geometry, once with linestring geometry. Is there any way to get around this?I know that polygons vs. linestrings in OSM are tricky (http://wiki.openstreetmap.org/wiki/Area/The_Future_of_Areas#Way-based_Polygons) but is there any way to tell to imposm3 which tags it should treat as polygons and which ones as lines (keeping the possibility to use mappings like
amenity: [__any__]
ortoursim: [__any__]
and similar)?