Selon Dennis Gocke <[email protected]>: > 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 > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
