<div dir="ltr"><div>Thanks for the information Even.</div><div> </div><div>I have created two tickets related to the OSM Driver issues.</div><div> </div><div> </div><div>Regarding the problems with the geocoding services.</div>
<div>It isn't really query dependant. A specific service behaves the same for all queries I tested.</div><div> </div><div>Anyway here is how it can be reproduced: </div><div> </div><div><font face="Consolas"><font face="Consolas">MAPQUEST:</font></font></div>
<div><font face="Consolas"><font face="Consolas">session = OGRGeocodeCreateSession({"SERVICE=MAPQUEST_NOMINATIM"});<br>layer = OGRGeocode(session, "london", null, null);</font></font></div><font face="Consolas"><font face="Consolas"><div>
<p>-> only first feature in layer has geometry</p><p> </p><p>GEONAMES:<br>session = OGRGeocodeCreateSession({"SERVICE=GEONAMES", "USERNAME=demo"});<br>layer = OGRGeocode(session, "london", null, null);</p>
<p>-> only first feature in layer has geometry</p><p> </p><p>BING:<br>session = OGRGeocodeCreateSession({"SERVICE=BING", "KEY=BingMapsKey"});<br>layer = OGRGeocode(session, "london", null, null);</p>
<p>-> layer is null and CPLGetLastErrorType does not report any error</p></div></font><div><p> </p><p>Best regards,<br>Dennis</p></div></font><div><p><br></p></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 18, 2013 at 1:11 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Selon Dennis Gocke <<a href="mailto:dengo@gmx.net">dengo@gmx.net</a>>:<br>
<br>
> Hi,<br>
><br>
> I ve encountered some issues. My tests are done with the latest 1.10<br>
> version.<br>
><br>
> The first issue is related to the new Geocoding API. Great work btw.<br>
><br>
> When using the MAPQUEST_NOMINATIM or GEONAMES service only the first<br>
> feature in the resulting layer gets a geometry. The other features only<br>
> report NULL as geometry. I think there might be a bug. When using the<br>
> OSM_NOMINATIM service all features have geometries.<br>
<br>
Could you point to a specific request you've issued ?<br>
<br>
><br>
> The other two services, that are hardcoded, don t seem to work at all. But<br>
> this is probably known and more of an issue on the server side. Calling<br>
> OGRGeocode on a YAHOO session produces the error Line 17: Didn't find<br>
> expected '=' for value of attribute '/'.<br>
<br>
Yahoo has retired their free service after the support for it had been added. It<br>
might still survive as a paying service however<br>
<br>
When using BING OGRGeocode does<br>
> not produce an error but the returned Layer is just NULL.<br>
<br>
Could you point to a specific request you've issued ?<br>
<br>
><br>
> The other issue is with reading an OSM file.<br>
><br>
> Firstly I have some questions regarding the interleaved reading.<br>
><br>
> For the driver to work with larger OSM files, the config option<br>
> OGR_INTERLEAVED_READING should be set and the interleaved reading scheme<br>
> should be used, correct?<br>
<br>
Yes. If you define OGR_INTERLEAVED_READING to YES, then you should apply the<br>
pattern given in the "Interleaved reading" paragraph of<br>
<a href="http://gdal.org/ogr/drv_osm.html" target="_blank">http://gdal.org/ogr/drv_osm.html</a><br>
<br>
><br>
> Are there other drivers that would benefit from the interleaved reading<br>
> scheme?<br>
<br>
The GML driver has a similar capability. See "Performance issues with large<br>
multi-layer GML files" section of <a href="http://gdal.org/ogr/drv_gml.html" target="_blank">http://gdal.org/ogr/drv_gml.html</a><br>
<br>
><br>
> Does this config option affect other drivers at all?<br>
<br>
No<br>
<br>
><br>
> Currently I only use the interleaved reading and set this config option<br>
> only temporarily while reading the OSM file.<br>
><br>
> The issue I m having is that I sometimes get a Failure on GetNextFeature<br>
> like Too many members referenced in relation 32572 . What consequences<br>
> does this failure have?<br>
<br>
Interesting. This means that your OSM file has a <relation> with more than 2000<br>
<member> in it, which is documented as something that should be avoided<br>
(<a href="http://wiki.openstreetmap.org/wiki/Relation" target="_blank">http://wiki.openstreetmap.org/wiki/Relation</a> indicates 300 as the recommanded<br>
max size, and the OSM XML parser currently implements a limit of 2000). How was<br>
that OSM file generated ? Could you create a Trac ticket and share it ?<br>
<br>
Anyway, I'll try to see if the limit can be dynamically increased.<br>
<br>
><br>
> If I just continue with the next layer in the interleaved reading scheme<br>
> get more features, but did I miss some features because of the failure?<br>
><br>
> If anyone is interested I can send a small test file where the failure can<br>
> be reproduced.<br>
><br>
> And finally I have a small suggestion regarding the osmconf.ini. I think<br>
> the waterway attribute should be default for lines as it usually is<br>
> important to differentiate for rivers ect.<br>
> Something like:<br>
> # keys to report as OGR fields<br>
> attributes=name,highway,waterway,aerialway,barrier,man_made<br>
<br>
Could you create a Trac ticket about that ?<br>
<br>
><br>
> Kind regards,<br>
> Dennis<br>
><br>
<br>
<br>
</blockquote></div><br></div></div>