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

[Dennis Gocke]

Thanks for the information Even.

I have created two tickets related to the OSM Driver issues.


Regarding the problems with the geocoding services.
It isn't really query dependant. A specific service behaves the same for
all queries I tested.

Anyway here is how it can be reproduced:

MAPQUEST:
session = OGRGeocodeCreateSession({"SERVICE=MAPQUEST_NOMINATIM"});
layer = OGRGeocode(session, "london", null, null);

-> only first feature in layer has geometry



GEONAMES:
session = OGRGeocodeCreateSession({"SERVICE=GEONAMES", "USERNAME=demo"});
layer = OGRGeocode(session, "london", null, null);

-> only first feature in layer has geometry



BING:
session = OGRGeocodeCreateSession({"SERVICE=BING", "KEY=BingMapsKey"});
layer = OGRGeocode(session, "london", null, null);

-> layer is null and CPLGetLastErrorType does not report any error



Best regards,
Dennis


On Thu, Apr 18, 2013 at 1:11 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130418/c5198294/attachment.html>