Re: [gdal-dev] osm_id vs osm_way_id?
georges wrote > Hello, > I am converting an .osm file to shapefile, and there is one thing that I > do not understand: > > What is the difference between: osm_id and osm_way_id fields (keys)? > > They are defined in osmconf.ini file, but only for [multipolygons]. > Here is an explanation from the osmconf.ini file: > > # note: for multipolygons, osm_id=yes instanciates a osm_id field for the > id of relations > # and a osm_way_id field for the id of closed ways. Both fields are > exclusively set. > Does that mean that osm_way_id will be used to represent the osm id number > of a closed way, while osm_id will only be used for to represent the osm > id number of relations? > > It's a bit confusing concept. > > What makes the closed ways so special so that they need to have their own > special field (osm_way_id)? > Why wasn't there a separate field for relations instead: like: > osm_relation_id, while closed ways would use the osm_id. > > Thank you for the reply. Indeed, OSM data model is a bit confusing concept. You can read about it from https://wiki.openstreetmap.org/wiki/Elements. Simple, small polygons are usually modeled as a one continuous, closed ring. That makes one "way" and the ID for it is found from way_id. All the other polygons are modeled as relations which are collections of ways and they have "relation_id" in the data as you can see node_id http://www.openstreetmap.org/api/0.6/node/389960161 way_id http://www.openstreetmap.org/api/0.6/way/34028339 relation_id http://www.openstreetmap.org/api/0.6/relation/125519 IDs are unique only for nodes/ways/relations but not across the elements. I do not think that renaming osm_id into relation_id (and probably osm_id of points into node_id, or?) and osm_way_id into way_id to follow the native model would make things very much more clear. -Jukka Rahkonen- -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-osm-id-vs-osm-way-id-tp5298287p5298304.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Append new data to GeoPackege raster table as overview
Even Rouault-2 wrote > The following works: > > gdal_translate Taustakartta_4milj.png test.gpkg -of gpkg -a_srs epsg:3067 > -expand rgba > gdal_translate Taustakartta_8milj.png Taustakartta_8milj_rgba.tif -expand > rgba > gdalwarp Taustakartta_8milj_rgba.tif test.gpkg -doo ZOOM_LEVEL=2 > > Expension to RGBA wouldn't be strictly needed in theory since your 2 > rasters have the same palette, > but in practice you have to do it. > > Even Oh yeah, naturally by polishing with gdalwarp and -doo. I would almost say "supernaturally". Thanks, I will remember this, and if I won't I can find it by searching "me+asking+something+tricky". -Jukka- -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Append-new-data-to-GeoPackege-raster-table-as-overview-tp5298214p5298218.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Append new data to GeoPackege raster table as overview
On jeudi 1 décembre 2016 11:45:43 CET Rahkonen Jukka (MML) wrote: > Hi, > > Let's say that I have these raster maps with 2048 m and 1024 m pixel sizes > http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_8m/2048m/ > etrs89/png/Taustakartta_8milj.png > http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_8m/2048m > /etrs89/png/Taustakartta_8milj.pgw > > http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_4m/1024m/ > etrs89/png/Taustakartta_4milj.png > http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_4m/1024m > /etrs89/png/Taustakartta_4milj.pgw > > Converting the 8milj.png into GeoPackage raster table is easy > > gdal_translate -of gpkg -a_srs epsg:3067 Taustakartta_8milj.png > overview.gpkg > > Image goes to zoom level 2 as reported by gdalinfo: > Metadata: > IDENTIFIER=overview > ZOOM_LEVEL=2 > > But now the hard part: I would like to append the second image 4milj.png to > the same layer "overview" as ZOOM_LEVEL=3 because that map is designed for > that resolution. Is it possible to do that by using some parameters of the > driver http://www.gdal.org/drv_geopackage_raster.html or with some clever > trick? The following works: gdal_translate Taustakartta_4milj.png test.gpkg -of gpkg -a_srs epsg:3067 -expand rgba gdal_translate Taustakartta_8milj.png Taustakartta_8milj_rgba.tif -expand rgba gdalwarp Taustakartta_8milj_rgba.tif test.gpkg -doo ZOOM_LEVEL=2 Expension to RGBA wouldn't be strictly needed in theory since your 2 rasters have the same palette, but in practice you have to do it. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Append new data to GeoPackege raster table as overview
Hi, Let's say that I have these raster maps with 2048 m and 1024 m pixel sizes http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_8m/2048m/etrs89/png/Taustakartta_8milj.png http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_8m/2048m/etrs89/png/Taustakartta_8milj.pgw http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_4m/1024m/etrs89/png/Taustakartta_4milj.png http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_4m/1024m/etrs89/png/Taustakartta_4milj.pgw Converting the 8milj.png into GeoPackage raster table is easy gdal_translate -of gpkg -a_srs epsg:3067 Taustakartta_8milj.png overview.gpkg Image goes to zoom level 2 as reported by gdalinfo: Metadata: IDENTIFIER=overview ZOOM_LEVEL=2 But now the hard part: I would like to append the second image 4milj.png to the same layer "overview" as ZOOM_LEVEL=3 because that map is designed for that resolution. Is it possible to do that by using some parameters of the driver http://www.gdal.org/drv_geopackage_raster.html or with some clever trick? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting multilayer KML to single layer output
Hey,
Thank you for your reponse.
Even Rouault-2 wrote
> I can't reproduce your issue with the file not being terminated with ]}
>
> Hum maybe this is due to trying to append several layers with layers[1:]
> syntax. You should
> probably
>
> Note that currently layers must be provided with an array, and not without
> a string
> (otherwise it iterates over each character of the string...) This is a
> defect I'm going to fix.
>
> Note also that the 'overwrite' mode is without effect here (and will
> actually not do what you
> want). overwrite is for multi-layer datasets where you want to overwrite
> an existing layer. In
> the GeoJSON driver, this is not implemented. You should just remove it and
> in that case the
> whole file will be overwritten.
You're right of course about 'layers' not accepting a string if you try to
specify a single layer, i noticed that mistake in my code later on as well.
Its not affecting the behavior i'm experiencing. I work in the Jupyter
Notebook and that moves you away from the console where the GDAL warnings
are printed, which is why i didn't noticed it right away. GDAL prints a nice
'ERROR 1: Couldn't fetch requested layer 'a'!' warning which makes the
sliced string obvious.
Even Rouault-2 wrote
> Actually I've just tested the following successfully (with trunk)
>
> from osgeo import gdal
>
> gdal.VectorTranslate('out.json', 'src', layerName = 'outlayer', format =
> 'GeoJSON',
> accessMode='append', layers = ['poly', 'poly2', 'poly3'])
Good to know that it should work like that, i started off with something
similar.
After some more trial and error i think I've found whats wrong. I was first
really focused on the keyword options, hence trying all access modes etc.
It turns out that its more a flushing/releasing issue, perhaps in
combination with the Jupyter Notebook (holding a reference to the object?).
If i display the returned dataset, Jupyter displays the string 'repr'. I do
this all the time with GDAL datasets just to confirm i actually have a
dataset, whereas a failed command would result in "None".
But somehow, in this case, closing the dataset with "ds = None" fails to
release the file handle (and doesnt flush?), but only when let Jupyter
display the dataset (repr). If i close the dataset right away, it works as
expected.
Here is a notebook showing what i did:
http://nbviewer.jupyter.org/gist/RutgerK/7da186e23b3ec20526c9a1c16c5cf98a
Is the method which doesn't work something that should work, or is it simply
bad practice? I'm pretty sure i do this with the raster utilities all the
time, without any problems.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Converting-multilayer-KML-to-single-layer-output-tp5298014p5298176.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WMTS - Need TileLevel option Servers responding with bad capabilities
esacree wrote > Question: Is it possible to get a TileLevel option added to the new GDAL > WMTS driver? > > Reason: WMTS servers at USGS and ESRI are returning XML Capabilities with > TileLevel 18 (Google) or TileLevel 19 (default028mm). The USGS help desk > said that the tile servers are only serving up to Tile Level 15. The new > GDAL WMTS driver always request data from the max TileLevel in the > Capabilities. The mismatch between the WMTS XML capabilities and the > actual maximum TileLevel are causing the GDAL WMTS driver requests to fail > with Error 404 (not found). > > I have requested that they correct the WMTS XML Capabilities documents. > > Suggestion: Could a "TileLevel" parameter be added to the WMTS GDAL > driver to limit the TileLevel to one that is available? A TileLevel > parameter would help work around this situation. > > Thanks! > > Elaine Hi, You can do what Even suggested in https://lists.osgeo.org/pipermail/gdal-dev/2016-November/045615.html: download and save GetCapabilities on the disk, edit, and read the edited GetCapabilities with GDAL. -Jukka Rahkonen- -- View this message in context: http://osgeo-org.1560.x6.nabble.com/WMTS-Need-TileLevel-option-Servers-responding-with-bad-capabilities-tp5298089p5298160.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
