[gdal-dev] 1.10 Issues with Geocing API and OSM Driver
Even Rouault
even.rouault at mines-paris.org
Thu Apr 18 04:11:15 PDT 2013
Selon Dennis Gocke <dengo at gmx.net>:
> Hi,
>
> Ive encountered some issues. My tests are done with the latest 1.10
> version.
>
> The first issue is related to the new Geocoding API. Great work btw.
>
> When using the MAPQUEST_NOMINATIM or GEONAMES service only the first
> feature in the resulting layer gets a geometry. The other features only
> report NULL as geometry. I think there might be a bug. When using the
> OSM_NOMINATIM service all features have geometries.
Could you point to a specific request you've issued ?
>
> The other two services, that are hardcoded, dont seem to work at all. But
> this is probably known and more of an issue on the server side. Calling
> OGRGeocode on a YAHOO session produces the error Line 17: Didn't find
> expected '=' for value of attribute '/'.
Yahoo has retired their free service after the support for it had been added. It
might still survive as a paying service however
When using BING OGRGeocode does
> not produce an error but the returned Layer is just NULL.
Could you point to a specific request you've issued ?
>
> The other issue is with reading an OSM file.
>
> Firstly I have some questions regarding the interleaved reading.
>
> For the driver to work with larger OSM files, the config option
> OGR_INTERLEAVED_READING should be set and the interleaved reading scheme
> should be used, correct?
Yes. If you define OGR_INTERLEAVED_READING to YES, then you should apply the
pattern given in the "Interleaved reading" paragraph of
http://gdal.org/ogr/drv_osm.html
>
> Are there other drivers that would benefit from the interleaved reading
> scheme?
The GML driver has a similar capability. See "Performance issues with large
multi-layer GML files" section of http://gdal.org/ogr/drv_gml.html
>
> Does this config option affect other drivers at all?
No
>
> Currently I only use the interleaved reading and set this config option
> only temporarily while reading the OSM file.
>
> The issue Im having is that I sometimes get a Failure on GetNextFeature
> like Too many members referenced in relation 32572. What consequences
> does this failure have?
Interesting. This means that your OSM file has a <relation> with more than 2000
<member> in it, which is documented as something that should be avoided
(http://wiki.openstreetmap.org/wiki/Relation indicates 300 as the recommanded
max size, and the OSM XML parser currently implements a limit of 2000). How was
that OSM file generated ? Could you create a Trac ticket and share it ?
Anyway, I'll try to see if the limit can be dynamically increased.
>
> If I just continue with the next layer in the interleaved reading scheme
> get more features, but did I miss some features because of the failure?
>
> If anyone is interested I can send a small test file where the failure can
> be reproduced.
>
> And finally I have a small suggestion regarding the osmconf.ini. I think
> the waterway attribute should be default for lines as it usually is
> important to differentiate for rivers ect.
> Something like:
> # keys to report as OGR fields
> attributes=name,highway,waterway,aerialway,barrier,man_made
Could you create a Trac ticket about that ?
>
> Kind regards,
> Dennis
>
More information about the gdal-dev
mailing list