[gdal-dev] splitting other_tags from .osm file

[Djordje Spasic]

Thank you for the replies Andre and Jukka.

@Andre:
 > It might be necessary torename addr:postcode to addr_postcode or 
postcode to avoid further problems with shapefile specifications. See 
http://support.esri.com/technical-article/000005588
Understood.


@Juka and Andre:
> other_tags includes all tagsthat are **not** covered by the attribute 
fields list in osmconf.ini.

all_tags includes really all tags of a feature, even if they are already 
in their respective column listed in osmconf.ini (like building or 
highway usually are).


> I apologize that I did notremember right what -all_tags is doing. The
difference is as written in http://www.gdal.org/drv_osm.html

"Similar to "other_tags", except that it contains both keysspecifically
identified to be reported as dedicated fields, as well as other keys."

Thus all_tags concatenates all tag/value pairs into one attribute (which is
designed for PostGIS HSTORE type) even if some keys are especially picked to
be written into regular attribute fields. Other_tags option concatenates
only those tag/value pairs which are not already converted into regular
attributes.  First option writes the selected attributes two times into
output data which does make sense with PostGIS hstore when it can be handy
to have everything queryable from hstore, but having same data as normal
attribute makes is also possible to use special index for the field, cast
strings to other datatypes etc. for some specialized queries and processing
of data.
Ah, I understand now.
What confused me was the following sentence from the GDAL OSM Driver page:

Similar to "other_tags", except that it contains both keys specifically identified to be reported asdedicated fields, as well as other keys.
The upper mentioned "dedicated fields" was the first and only mention of "dedicated fields" on that page. After your last replies I understood that this is actually related with the part of the osmconf.ini file, which defines the particular fields. For example:

# keys to report as OGR fields
attributes=name,type,aeroway,amenity,admin_level,barrier,boundary,building,craft,geological,historic,land_area,landuse,leisure,man_made,military,natural,office,place,shop,sport,tourism




@ Jukka:
> If youneed to get access to all the tag/value pairs in the data you may
bang your head on the wall with ogr2ogr and shapefiles. Some suggestions: 
- Use ogr2ogr and PostGIS with hstore + all_tags
- Try OpenJUMP which creates fields for all the tags it finds.
- QGIS was already suggested
- Try Spatialite OSM raw toolhttps://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=spatialite_osm_raw
It's good to know this. I will have to stick with shapefiles for now.
But I can see that OGR2OGR can convert an .osm file to PostgreSQL format, so I assume this may be useful later. But I would have to become familiar with PostgreSQL format first.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161030/c6457282/attachment-0001.html>