[gdal-dev] 1.10 Issues with Geocing API and OSM Driver

[Even Rouault]

Selon Dennis Gocke <dengo at gmx.net>:

> Hi,
>
> I’ve 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, don’t 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 I’m 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
>