Re: [gdal-dev] WAsP map output for ogr
On 11/03/2014 14:58, Even Rouault wrote: Selon Vincent Mora vincent.m...@oslandia.com: On 11/03/2014 10:39, Even Rouault wrote: If you want to test the compliance of your driver (the read part) with the assumptions of the OGR API, you can go to the apps subdirectory of GDAL and make test_ogrsf, and then test_ogrsf a_wasp_file. Thanks for the tip. It helped me fix some issues, and raises one question: test_ogrsf now fails with 'ExecuteSQL() should have returned a non-NULL result', should I implement all the sql queries that are specified in http://www.gdal.org/ogr/ogr_sql.html for my driver to be OK ? You should completely remove your ExecuteSQL() implementation. The generic one in OGRDataSource should be sufficient. I found my problem with the default ExecuteSQL() implementation: I was naming my layer filename.map and the extension was messing with the table_name.column_name parsing. Fixed and pushed now, test_ogrsf passes. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WAsP map output for ogr
I've question concerning SRS: what should OGRWAsPLayer::GetSpatialRef() for unknown SRS. Context: WAsP Map Editor has a couple of SRS that will be written in the first line of the .map file. The first line looks like +description | srs_name | map_editor version Since there are very few SRS available, I use the 'description' field to write the proj4 of the source SRS when I create a .map file (e.g. with ogr2ogr -f WAsP dest.wasp source.shp). I want to open .map files that where created by other means (e.g. WAsP Map Editor). In this case the SRS will be unknown and it's fine since it can be defined by other means e.g. with option -s_srs. But I don't wan't the driver to do stupid things in this case. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WAsP map output for ogr
Le mercredi 12 mars 2014 08:53:44, Vincent Mora a écrit : I've question concerning SRS: what should OGRWAsPLayer::GetSpatialRef() for unknown SRS. NULL would be OK. Context: WAsP Map Editor has a couple of SRS that will be written in the first line of the .map file. The first line looks like +description | srs_name | map_editor version Since there are very few SRS available, I use the 'description' field to write the proj4 of the source SRS when I create a .map file (e.g. with ogr2ogr -f WAsP dest.wasp source.shp). I want to open .map files that where created by other means (e.g. WAsP Map Editor). In this case the SRS will be unknown and it's fine since it can be defined by other means e.g. with option -s_srs. But I don't wan't the driver to do stupid things in this case. Well, you could probably put in your driver the code that will recognize the most used srs_name written by the WasP Map Editor and turn them into a valid OGRSpatialReference ? and for unknown values, return NULL. -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problem fixing the Starting point of a tiling job
Dear Experts, When tiling datasets, we want to specifically define custom windows. To do this, we are using -te option during warping. The warped output is then tiled. The problem though is that after tiling and checking the bbox of the first tile, we have noticed that the starting coordinate is shifted and do not correspond to the defined starting coordinates as illustrated below: * The blue grid represent the original dataset with cellsize (a). * The black grid represent the new dataset with cellsize (b). * The cellsize of both datasets can be the same or not [(a) .eq. (b) or (a) .ne. (b)]. * The red polygon represent the bbox which fit to the new cellsize and tilesize. We would like to start tiling exactly at the upper left corner of the red polygon.How we can force gdal to clip the raster exactly according to our well defined bbox? In some cases, GDAL picks the right Bbox startpoint, in other cases it doesnt. Is this somehow related to the difference in the input and output data resolution(cellsize)? We can't figure out why it is ignoring our definitions. Could someone help shade some light to what is happening here? Thanks in advance, Moses inline: BBox_def.png___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal GeoTIFFs in MapInfo
Le mardi 11 mars 2014 12:19:36, Jonathan Moules a écrit : Hi List, I've created a GeoTIFF with GDAL. It works fine in QGIS and ArcMap, but MapInfo refuses to load it, giving me a Image file open error message. I've come across several problems and was wondering if anyone else had experience with GDAL created files in MapInfo. Problems: 1) MapInfo can't handle compressed overviews ( *--config COMPRESS_OVERVIEW DEFLATE*) - I can easily get past this one by not compressing them. 2) However, my next problem is that MapInfo can't read the projection information from within the file. Is GDAL capable of creating a TAB file? Not currently. It can read them, and it is used in a few drivers such as GTiff. Writing is done only in the MapInfo TAB driver for the vector part. The writing of .tab for raster files would only be a matter of implementing it... 3) Finally, while MapInfo will happily open my small subset sample (above issues not withstanding), it won't load my full image (about 2GB). Both are created using the exact same commands: gdalbuildvrt -srcnodata - -vrtnodata - -input_file_list asc_list.txt merged_vrt.vrt gdal_translate -of GTiff -co TILED=YES -co COMPRESS=DEFLATE -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -a_srs EPSG:27700 merged_vrt.vrt DSM_2012-13.tif gdaladdo -r average DSM_2012-13.tif 2 4 8 16 32 64 It's not the overviews because it still happens when they're not generated. Well, I don't know MapInfo limits with raster files. Perhaps is it just big raster dimensions that cause problem, or tiling, or .. ? Thoughts welcome, Jonathan -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem fixing the Starting point of a tiling job
Hi Moses, when starting coordinate is shifted, is it a large shift ? Are you using gdalwarp command only for tiling or did you change SRS (-t_srs) too ? Regards. Mathieu LATTES http://www.interatlas.fr/ http://www.interatlas.fr http://www.urbimap.com/ http://www.ubick.net De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] De la part de moses.g...@t-systems.com Envoyé : mercredi 12 mars 2014 11:22 À : gdal-dev@lists.osgeo.org Objet : [gdal-dev] Problem fixing the Starting point of a tiling job Dear Experts, When tiling datasets, we want to specifically define custom windows. To do this, we are using -te option during warping. The warped output is then tiled. The problem though is that after tiling and checking the bbox of the first tile, we have noticed that the starting coordinate is shifted and do not correspond to the defined starting coordinates as illustrated below: * The blue grid represent the original dataset with cellsize (a). * The black grid represent the new dataset with cellsize (b). * The cellsize of both datasets can be the same or not [(a) .eq. (b) or (a) .ne. (b)]. * The red polygon represent the bbox which fit to the new cellsize and tilesize. We would like to start tiling exactly at the upper left corner of the red polygon.How we can force gdal to clip the raster exactly according to our well defined bbox? In some cases, GDAL picks the right Bbox startpoint, in other cases it doesnt. Is this somehow related to the difference in the input and output data resolution(cellsize)? We cant figure out why it is ignoring our definitions. Could someone help shade some light to what is happening here? Thanks in advance, Moses --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com image001.png___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Heuristics to classify raster data ?
Hi all, I think the fastest and simplest way to class maps and aerial/satellite is to count number of colors. Generally maps of OSM have a maximum of 20 or may e 30 colors. I don't think OSM will use all 256 colors in their maps. About k-means, some people use it to filter aerial/satellite with too much clouds (or snow). When the cluster of white and bright colors is too large (in histograms) then the raster is considered having too much clouds. Because maps must be the most readable, colors are visually separated. It may be possible by compute each cluster of each band or compare each border or center of clusters. Another solution may be to get the quantity or the coverage of some colors. Generally maps have one or few background colors. If one or two colors are very dominant than others, the raster may be considered as a map. I think the minimum is two if a part of the map have some water. Florent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal GeoTIFFs in MapInfo
Hi Even, Well, I don't know MapInfo limits with raster files. Perhaps is it just big raster dimensions that cause problem, or tiling, or .. ? I guess it's size. I've tried with no compression, no tiles, and both no compression or tiling, all fail. So I guess a MapInfo thing then. Thanks, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal GeoTIFFs in MapInfo
What about using a world file for the projection info? It is an Esri thing, but maybe MapInfo will recognize it. Just add a -co TFW=YES to the gdal_translate command. Eric On Wed, Mar 12, 2014 at 7:44 AM, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: Hi Even, Well, I don't know MapInfo limits with raster files. Perhaps is it just big raster dimensions that cause problem, or tiling, or .. ? I guess it's size. I've tried with no compression, no tiles, and both no compression or tiling, all fail. So I guess a MapInfo thing then. Thanks, Jonathan This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic
Hi David, Here's a crazy idea could you perhaps use mm and then output to an integer raster? No problem representing 50597mm. I like you thinking! But on reflection suspect that would confound a few too many of our users. It's certainly a nice lateral-thinking solution to bear in mind for the future though. Thanks! Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem fixing the Starting point of a tiling job
Moses.Gone at t-systems.com writes: Dear Experts, When tiling datasets, we want to specifically define custom windows. To do this, we are using -te option during warping. The warped output is then tiled. The problem though is that after tiling and checking the bbox of the first tile, we have noticed that the starting coordinate is shifted and do not correspond to the defined starting coordinates as illustrated below: The blue grid represent the original dataset with cellsize (a). The black grid represent the new dataset with cellsize (b). The cellsize of both datasets can be the same or not [(a) .eq. (b) or (a) .ne. (b)]. The red polygon represent the bbox which fit to the new cellsize and tilesize. We would like to start tiling exactly at the upper left corner of the red polygon.How we can force gdal to clip the raster exactly according to our well defined bbox? Option -tap can help at least a bit. http://www.gdal.org/gdalwarp.html -Jukka Rahkonen- In some cases, GDAL picks the right Bbox startpoint, in other cases it doesnt. Is this somehow related to the difference in the input and output data resolution(cellsize)? We can’t figure out why it is ignoring our definitions. Could someone help shade some light to what is happening here? Option -tap can help at least a bit. Thanks in advance, Moses ___ gdal-dev mailing list gdal-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal GeoTIFFs in MapInfo
Eric Goddard egoddard1010 at gmail.com writes: What about using a world file for the projection info? It is an Esri thing, but maybe MapInfo will recognize it. Just add a -co TFW=YES to the gdal_translate command. I may remember wrong and I do not have Mapinfo at hands now, but I bet that it at least used to be so that you first _import_ GeoTIFFs with Mapinfo and it creates a tab file. Later you can _open_ the tab. If that fails it may mean that Mapinfo does not recognize the projection of the GeoTIFF. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic
On 03/12/2014 06:58 AM, Jonathan Moules wrote: Hi David, Here's a crazy idea could you perhaps use mm and then output to an integer raster? No problem representing 50597mm. I like you thinking! But on reflection suspect that would confound a few too many of our users. It's certainly a nice lateral-thinking solution to bear in mind for the future though. I'm still new to this stuff but couldn't you embed the mm thing in a custom CRS so the users didn't even see it? Thanks! Jonathan This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] CSV to CSV?
I can't get a direct CSV to CSV conversion to work. Taking one of the NGA geoname country files, I created a csvt for field types and a vrt to assign the SRS. This: ogr2ogr -select ufi,uni,cc1,adm1,dsg,full_name_ro \ -where fc = 'P' and (nt = 'N' or nt = 'D' or nt = 'P') \ -f CSV -lco GEOMETRY=AS_XY -lco SEPARATOR=TAB -lco CREATE_CSVT=YES \ ca_pp.csv ca.vrt tells me that Layer ca already exists. But that's the input layer/source! It will convert to shapefile: ogr2ogr -select ufi,uni,cc1,adm1,dsg,full_name_ro \ -where fc = 'P' and (nt = 'N' or nt = 'D' or nt = 'P') \ ca_pp ca.vrt - ca_pp/ca.shp But I can't convert that to CSV, I get the same error Layer ca already exists. Converting to postgis, then extracting to CSV works (same select, where and lco options). - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
