Re: [gdal-dev] OGR SQL: Excecuting select where column name contains .
Thanks for the response. I think I will conclude the same as you, and report back to the server developers that this is a bad idea. Odd-Ragnar -Original Message- From: Rahkonen Jukka [mailto:jukka.rahko...@mmmtike.fi] Sent: 8. oktober 2012 22:22 To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] OGR SQL: Excecuting select where column name contains . Even Rouault wrote: I can confirm that it is not illegal per se because the following works. I hope that the backslashes and everything go through properly. ogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows -sql select \nom.dept\ from \tows:dot.test\ It is an open WFS server and you can test it with ogrinfo and from your code too. However, I will remove the dot.test feature type sooner or later. Verify and make your code to work in a similar way than ogrinfo. Jukka, I didn't do any test up to now, but now that I've tested with your above server, here are my findings and conclusions. To start, I'm wondering to which extent did you check the result of the above ogrinfo command. It works for me on GDAL 1.9.2 and GDAL trunk on Linux and Windows, but the output is what Odd-Ragna actually observes, something like : FIELD_1: String (0.0) I feel ashamed and made one more test to compansate my lazy interpretation that if TinyOWS is sending something back it is then all right. HTTP POST tends to be more reliable when making complicated WFS requests so I tried that method by sending directly to the server the following GetFeature: POST http://188.64.1.61/cgi-bin/tinyows HTTP/1.1 Content-Type: text/xml User-Agent: Jakarta Commons-HttpClient/3.0-beta1 Host: 188.64.1.61 Connection: Keep-Alive Content-Length: 404 wfs:GetFeature xmlns:ogc=http://www.opengis.net/ogc; xmlns:gml=http://www.opengis.net/gml; xmlns:wfs=http://www.opengis.net/wfs; service=WFS version=1.0.0 maxFeatures=1000 outputFormat=GML2wfs:Query xmlns:tows=http://www.tinyows.org/; typeName=tows:dot.testogc:PropertyNametows:nom.dept/ogc:PropertyNameogc:PropertyNametows:the_geom/ogc:PropertyName/wfs:Query/wfs:GetFeature TinyOWS gives an error ?xml version=1.0 encoding=UTF-8? ServiceExceptionReport xmlns=http://www.opengis.net/ogc; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.opengis.net/ogc http://schemas.opengis.net/wms/1.1.1/OGC-exception.xsd; version=1.2.0 ServiceException code=NoMatching locator=GetFeature propertyname values and typename values don't match/ServiceException /ServiceExceptionReport There may be something wrong with TinyOWS but it must be noted that it has passed all the CITE tests for WFS 1.0.0 and 1.1.0. If so well tested server fails with dots in the field names it is very probable that there are lots of other servers and clients which will fail too. Conclusion: Do not use dots in names if you hope it to work. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR SQL: Excecuting select where column name contains .
The problem is OGRSQL (ogr_gensql.cpp) which adds the string FIELD_%d when it doesn't know how to handle column names with dot character in them. Because the dot character is a special/reserved character it needs to be enclosed in '', , ``, [], ..., all depending on which dialect is used (MS SqlServer, Oracle, MySQL, SqlLite, ...) So it seems that to me that this is not legal in OGRSQL Odd-Ragnar -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: 8. oktober 2012 22:42 To: gdal-dev@lists.osgeo.org Cc: Rahkonen Jukka Subject: Re: [gdal-dev] OGR SQL: Excecuting select where column name contains . There may be something wrong with TinyOWS but it must be noted that it has passed all the CITE tests for WFS 1.0.0 and 1.1.0. If so well tested server fails with dots in the field names it is very probable that there are lots of other servers and clients which will fail too. The CITE tests don't necessarily test all corner cases of implementations. They test the requirements and the protocol of the standard, so there are likely many holes in the test coverage. For example, I believe that a WFS/WMS implementation can pass the CITE tests but may not behave properly with the annoying axis ordering problem when using real world datasets (for example when serving a shapefile that uses the standard long/lat ordering and whose coordinates must be swapped when going from/to WFS 1.1) I've looked at WFS 1.1 spec, and at page 17 (§7.3 Property names), I see that the definition of the property name allows a dot character. So this is theoretically valid... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR SQL: Excecuting select where column name contains .
Even Rouault even.rouault at mines-paris.org writes: I've looked at WFS 1.1 spec, and at page 17 (§7.3 Property names), I see that the definition of the property name allows a dot character. So this is theoretically valid... TinyOWS is now theoretically fixed https://github.com/mapserver/tinyows/issues/17 I had also a test with Mapserver and it did handle dot.attribute names OK. However, I had to rename my dot.table because Mapserver got lost when querying the table for getting the schema. [Tue Oct 9 10:56:02 2012].214191 msPostGISLayerGetItems(): Query error. Error (ERROR: schema dot does not exist LINE 1: select * from dot.test where false limit 0 ^ ) executing SQL: select * from dot.test where false limit 0 [Tue Oct 9 10:57:12 2012].923891 msPostGISLayerGetItems(): Query error. Error (ERROR: schema dot does not exist LINE 1: select * from dot.test where false limit 0 ^ ) executing SQL: select * from dot.test where false limit 0 I do not have Geoserver in my hands right now but I believe that this has been enough to prove that dots in attribute and feature type names will make so many clients and servers to fail that it should be considered as Bad Practice. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] clipping multiple shapefiles from a set of clipping polygons
I see, is there a scripting workaround using 1.9? On Mon, Oct 8, 2012 at 9:14 PM, Etienne Tourigny etourigny@gmail.com wrote: generally speaking new features do not go into current stable version (1.9), they will be incorporated into next stable version (probably 2.0). Etienne On Mon, Oct 8, 2012 at 9:57 AM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 03:21 PM, maning sambale wrote: Thanks! Is this implemented already in the stable build? It's currently only in the trunk version. Ari Maning Sambale (mobile) On Oct 8, 2012 7:28 PM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 02:13 PM, maning sambale wrote: HI, I have a shapefile polygon that contains administrative boundaries and a several shapefile of various features. I want to create separate shapefiles of each layer feature for each administrative boundaries in the clipping layer. For example, AdminPoly1 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp AdminPoly2 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp and so on. Any advice? Maning, The new layer methods may be what you're looking for: http://trac.osgeo.org/gdal/wiki/LayerAlgebra Ari ___ 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 -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Small meshing utility
On Sun, Oct 7, 2012 at 8:33 PM, Tim Keitt tke...@gmail.com wrote: cool! though Im a little confused as to how this fits with OGR. OGR is used for i/o. I see -- so you've written something like the triangle command line utility, but with OGR for IO, so you don't need to use triangles particular data file format? sounds useful. Also -- how did you deal with the fact that triangle calls the system exit() function on error -- that could bring down whatever your host process is. Its a simple command line utility. Not much harm done if it calls exit. I see -- I was thinking you'd extended the OGR library, rather than the OGR command line tools. I get it now. We've written a wrapper around triangle for Python (anyone feel free to send me a note if you're interested), and we ended up handling that by spawning another process to run triangle in -- but that has performance issues (copying data around) which would be nice to avoid. I don't call triangle, I pass arguments to the C-level API. neither do we -- we also use the C-API -- but if you need to run it in another process you need to ass the data around somehow -- and if you want to call it as a library from a longer-running application, then the calls to exit() will kill you (well, kill your app...) if you don't run it in another process. If only triangle has a nicer licensing scheme -- it really is a nice utility. Only prohibition is you can't sell it without a license. well, commercial is not clearly defined in the license -- why not just GPL the darn thing! and it's not BSD-compatible in any case. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] clipping multiple shapefiles from a set of clipping polygons
On Tue, Oct 9, 2012 at 3:41 AM, maning sambale emmanuel.samb...@gmail.com wrote: I see, is there a scripting workaround using 1.9? ogr2ogr has various -clip. options. It looks like you could specify using a particular feature in the AdminPoly to do this (presumably GEOS support is required?). ogr2ogr -f ESRI shapefile output.shp input.shp -clipsrc AdminPoly.shp -clipsrclayer AdminPoly -clipsrcsql SELECT * FROM AdminPoly WHERE AttributeName_in_AdminPoly='Some_value' If you don't have other requirements for the stable release, there are lots of binaries including nightly builds for some platforms, http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries HTH, Eli On Mon, Oct 8, 2012 at 9:14 PM, Etienne Tourigny etourigny@gmail.com wrote: generally speaking new features do not go into current stable version (1.9), they will be incorporated into next stable version (probably 2.0). Etienne On Mon, Oct 8, 2012 at 9:57 AM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 03:21 PM, maning sambale wrote: Thanks! Is this implemented already in the stable build? It's currently only in the trunk version. Ari Maning Sambale (mobile) On Oct 8, 2012 7:28 PM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 02:13 PM, maning sambale wrote: HI, I have a shapefile polygon that contains administrative boundaries and a several shapefile of various features. I want to create separate shapefiles of each layer feature for each administrative boundaries in the clipping layer. For example, AdminPoly1 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp AdminPoly2 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp and so on. Any advice? Maning, The new layer methods may be what you're looking for: http://trac.osgeo.org/gdal/wiki/LayerAlgebra Ari ___ 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 -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ 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] S57 dataset boundary issue
On Mon, Oct 8, 2012 at 10:28 PM, Nikhil Sai Parupalli nikhil.parupa...@iictechnologies.com wrote: HI All, , Thanks for the reply in below data NAME_RCNM (IntegerList) = (7:130,130,130,130,130,130,130) NAME_RCID (IntegerList) = (7:691,391,690,52,1336,1503,1512) ORNT (IntegerList) = (7:2,2,2,2,1,1,1) USAG (IntegerList) = (7:1,1,1,1,1,1,1) MASK (IntegerList) = (7:255,255,255,255,255,255,255) RCID 691 ORNT has 2 and USAG is 1 based on this data we could identify that RCID 691 is of exterior boundary with reverse direction. So if I have 1000 RCID in NAME_RCID which is vise versa for the above condition I need to display that RCIDS list as errors. So it makes 1000 conditional checks hence reducing performance. Please let us know further. Nikhil, I'm afraid I don't follow your point. Are you trying to do some sort of ring orientation validation and identify ones that don't match your expectations? And you are concerned about the performance cost? I don't know why you are doing this, and if you are, I'm not sure what I or others can do about the performance cost of checking. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: Release 1.9.2
Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the official GDAL/OGR 1.9.2 release. --- PSC members are encouraged to review the release candidate and vote. Non-PSC members are encouraged to review the release candidate and comment here on problems. The motion will be open for two days for voting. +1 Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Release 1.9.2
On 12-10-09 12:27 PM, Frank Warmerdam wrote: Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the official GDAL/OGR 1.9.2 release. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Strange errors with large vrt
I'm trying to make a world-wide hillshade dataset filling SRTM void from Aster, and using Aster data only between 60°N and 72°N. I computed all 1x1° hillshade tiles, but now I'm struggling to work with a vrt. If I make a .vrt of all ~29'000 single 1x1° tiles, I don't have any data above 60°N, neither with Mapnik gdal datasource, nor gdal_translate, nor gdal2tiles. But if I make a small 38-files .vrt around 60°N, gdal_translate with a -projwin works well. Maybe someone can see a difference between hillshade2_N58E164.tif and hillshade2_N63E164.tif ? See gdalinfo below, I don't. Also, vrt files and some tiles can be found at http://www.pistes-nordiques.org/download/extract.zip (16MB). Yves GDAL 1.9.1, released 2012/05/15 $ gdalinfo extract/hillshade2_N58E164.tif Driver: GTiff/GeoTIFF Files: extract/hillshade2_N58E164.tif Size is 786, 1505 Coordinate System is: PROJCS[unnamed, GEOGCS[unnamed ellipse, DATUM[unknown, SPHEROID[unnamed,6378137,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (18256303.723854541778564,8180567.003424840979278) Pixel Size = (141.656454553493091,-141.656454553493091) Metadata: AREA_OR_POINT=Area TIFFTAG_DOCUMENTNAME=slopes/hillshade2_N58E164.tif TIFFTAG_RESOLUTIONUNIT=1 (unitless) TIFFTAG_XRESOLUTION=72 TIFFTAG_YRESOLUTION=72 Image Structure Metadata: COMPRESSION=DEFLATE INTERLEAVE=PIXEL Corner Coordinates: Upper Left (18256303.724, 8180567.003) (163d59'57.00E, 59d 0' 3.00N) Lower Left (18256303.724, 7967374.039) (163d59'57.00E, 58d 0' 0.97N) Upper Right (18367645.697, 8180567.003) (164d59'57.73E, 59d 0' 3.00N) Lower Right (18367645.697, 7967374.039) (164d59'57.73E, 58d 0' 0.97N) Center (18311974.710, 8073970.521) (164d29'57.36E, 58d30'14.82N) Band 1 Block=786x1505 Type=Byte, ColorInterp=Gray Mask Flags: PER_DATASET ALPHA Band 2 Block=786x1505 Type=Byte, ColorInterp=Alpha $ gdalinfo extract/hillshade2_N63E164.tif Driver: GTiff/GeoTIFF Files: extract/hillshade2_N63E164.tif Size is 692, 1551 Coordinate System is: PROJCS[unnamed, GEOGCS[unnamed ellipse, DATUM[unknown, SPHEROID[unnamed,6378137,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (18256381.029056482017040,9349799.443527495488524) Pixel Size = (160.906779712378437,-160.906779712378437) Metadata: AREA_OR_POINT=Area TIFFTAG_DOCUMENTNAME=slopes/hillshade2_N63E164.tif TIFFTAG_RESOLUTIONUNIT=1 (unitless) TIFFTAG_XRESOLUTION=72 TIFFTAG_YRESOLUTION=72 Image Structure Metadata: COMPRESSION=DEFLATE INTERLEAVE=PIXEL Corner Coordinates: Upper Left (18256381.029, 9349799.444) (163d59'59.50E, 64d 0' 0.50N) Lower Left (18256381.029, 9100233.028) (163d59'59.50E, 62d59'59.74N) Upper Right (18367728.521, 9349799.444) (165d 0' 0.41E, 64d 0' 0.50N) Lower Right (18367728.521, 9100233.028) (165d 0' 0.41E, 62d59'59.74N) Center (18312054.775, 9225016.236) (164d29'59.95E, 63d30'15.88N) Band 1 Block=692x1551 Type=Byte, ColorInterp=Gray Mask Flags: PER_DATASET ALPHA Band 2 Block=692x1551 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Release 1.9.2
On Oct 9, 2012, at 11:34 AM, Daniel Morissette dmorisse...@mapgears.com wrote: On 12-10-09 12:27 PM, Frank Warmerdam wrote: Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the official GDAL/OGR 1.9.2 release. +1 Daniel +1 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] S57 dataset boundary issue
Frank Nikhil,
Frank asked:
are, I'm not sure what I or others can do about
the performance cost of checking.
If I understand the problem, then it cost nothing!
You have to check the winding while loading a OGRGeometryH
like so:
double area = 0;
for (unsigned int i=0; ivert_count-1; i++) {
double x1 = OGR_G_GetX(hRing, i);
double y1 = OGR_G_GetY(hRing, i);
double x2 = OGR_G_GetX(hRing, i+1);
double y2 = OGR_G_GetY(hRing, i+1);
area += (x1*y2) - (x2*y1);
}
If the area 0 then it is CW (clockwise) and 0 is CCW (Counter CW).
Note that in S57 the exterior ring must be CW and
interior ring are CCW.
But in S57 there is no order between rings. So interior ring
might come first. I think WKT fix this. In my code I assume
that OGR place the exterior ring first.
We have been trough this before. At the time the question
was if S57 allow for many exterior ring for the same poly.
I guess it all depend on HO and how they encode the data.
I'm using mostly Canadian ENC and found no problem.
But other HO might encode ENC differently ..
rdgs,
Sylvain Duclos.
From: Frank Warmerdam warmer...@pobox.com
To: Nikhil Sai Parupalli nikhil.parupa...@iictechnologies.com
Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org
Sent: Tuesday, October 9, 2012 12:25:29 PM
Subject: Re: [gdal-dev] S57 dataset boundary issue
On Mon, Oct 8, 2012 at 10:28 PM, Nikhil Sai Parupalli
nikhil.parupa...@iictechnologies.com wrote:
HI All,
,
Thanks for the reply in below data
NAME_RCNM (IntegerList) = (7:130,130,130,130,130,130,130)
NAME_RCID (IntegerList) = (7:691,391,690,52,1336,1503,1512)
ORNT (IntegerList) = (7:2,2,2,2,1,1,1)
USAG (IntegerList) = (7:1,1,1,1,1,1,1)
MASK (IntegerList) = (7:255,255,255,255,255,255,255)
RCID 691 ORNT has 2 and USAG is 1 based on this data we could identify that
RCID 691 is of exterior boundary with reverse direction.
So if I have 1000 RCID in NAME_RCID which is vise versa for the above
condition I need to display that RCIDS list as errors.
So it makes 1000 conditional checks hence reducing performance.
Please let us know further.
Nikhil,
I'm afraid I don't follow your point. Are you trying to
do some sort of ring orientation validation and identify
ones that don't match your expectations? And you
are concerned about the performance cost?
I don't know why you are doing this, and if you
are, I'm not sure what I or others can do about
the performance cost of checking.
Best regards,--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer
___
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] Strange errors with large vrt
Le mardi 09 octobre 2012 19:08:33, yvecai a écrit : I'm trying to make a world-wide hillshade dataset filling SRTM void from Aster, and using Aster data only between 60°N and 72°N. I computed all 1x1° hillshade tiles, but now I'm struggling to work with a vrt. If I make a .vrt of all ~29'000 single 1x1° tiles, I don't have any data above 60°N, neither with Mapnik gdal datasource, nor gdal_translate, nor gdal2tiles. Did you check that there was no error or warning reported when building the VRT ? What do you mean by I don't have any data ? Do you mean that if you do an extraction from that VRT, you get no significant data ? What does gdalinfo report on the generated VRT ? Does it reported extent goes above 60° ? But if I make a small 38-files .vrt around 60°N, gdal_translate with a -projwin works well. Maybe someone can see a difference between hillshade2_N58E164.tif and hillshade2_N63E164.tif ? See gdalinfo below, I don't. I don't see any difference... But all the files you provided in the archive are definitely odd : their first band is set to 0. Only the 2nd band (alpha band= has non uniform data. So that might explain what you saw with the huge .vrt Also, vrt files and some tiles can be found at http://www.pistes-nordiques.org/download/extract.zip (16MB). No VRT files in that zip. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Small meshing utility
On Tue, Oct 9, 2012 at 11:07 AM, Chris Barker chris.bar...@noaa.gov wrote: On Sun, Oct 7, 2012 at 8:33 PM, Tim Keitt tke...@gmail.com wrote: cool! though Im a little confused as to how this fits with OGR. OGR is used for i/o. I see -- so you've written something like the triangle command line utility, but with OGR for IO, so you don't need to use triangles particular data file format? sounds useful. Also -- how did you deal with the fact that triangle calls the system exit() function on error -- that could bring down whatever your host process is. Its a simple command line utility. Not much harm done if it calls exit. I see -- I was thinking you'd extended the OGR library, rather than the OGR command line tools. I get it now. We've written a wrapper around triangle for Python (anyone feel free to send me a note if you're interested), and we ended up handling that by spawning another process to run triangle in -- but that has performance issues (copying data around) which would be nice to avoid. I don't call triangle, I pass arguments to the C-level API. neither do we -- we also use the C-API -- but if you need to run it in another process you need to ass the data around somehow -- and if you want to call it as a library from a longer-running application, then the calls to exit() will kill you (well, kill your app...) if you don't run it in another process. If only triangle has a nicer licensing scheme -- it really is a nice utility. Only prohibition is you can't sell it without a license. well, commercial is not clearly defined in the license -- why not just GPL the darn thing! and it's not BSD-compatible in any case. I don't have any plans to sell software that includes triangle, so I'm not concerned. We don't distribute it either with our code, so that is not a problem. You could probably sell software that required the user to build triangle and be perfectly legit if you were so inclined. I don't think what is written on the triangle web site is really enforceable unless you distributed the triangle code or compiled library with your software. The author's wishes mean that triangle will likely remain stand-alone and not incorporated into FOSS projects, but that is perfectly fine for my uses of the library. THK -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Timothy H. Keitt http://www.keittlab.org/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Release 1.9.2
Le mardi 09 octobre 2012 18:27:29, Frank Warmerdam a écrit : Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the official GDAL/OGR 1.9.2 release. +1 Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] [ OGR SQL: Excecuting select where column name starts with _ SO: Windows 7, GDAL/OGR 1.9.x
Hi, I´m getting a sql parsing error when I tried to execute a query to a shapefile where column name starts with _. When i execute a query like : ogrinfo Provincias.shp -sql SELECT * FROM Provincias WHERE tipo = 1 INFO: Open of `Provincias.shp' using driver `ESRI Shapefile' successful. Layer name: Provincias Geometry: Line String Feature Count: 21 Extent: (309062.03, 3895521.90) - (2039227.59, 7591083.24) Layer SRS WKT: PROJCS[500K, GEOGCS[GCS_WGS_1984, DATUM[WGS_1984, SPHEROID[WGS_84,6378137.0,298.257223563]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.017453292519943295]], PROJECTION[Transverse_Mercator], PARAMETER[False_Easting,100.0], PARAMETER[False_Northing,0.0], PARAMETER[Central_Meridian,-64.0], PARAMETER[Scale_Factor,1.0], PARAMETER[Latitude_Of_Origin,-90.0], UNIT[Meter,1.0]] ID: String (1.0) _tipo_Area: Integer (10.0) _desc_Area: String (1.0) tipo: Integer (10.0) OGRFeature(Provincias):29 ID (String) = 0 _tipo_Area (Integer) = 1 _desc_Area (String) = (null) tipo (Integer) = 1 LINESTRING (873405.76 7463549.34,873313.54 7463695.39,872765.09 7465104.71,872 623.98 7465495.26) But when i want to execute a query like SELECT * FROM Provincias WHERE _tipoArea = 1 ogrinfo Provincias.shp -sql SELECT * FROM WHERE _tipo_Area = 1 INFO: Open of `Provincias.shp' using driver `ESRI Shapefile' successful. ERROR 1: SQL Expression Parsing Error: syntax error Any ideas on how to get around this? Best regards, -- Gabriel Fusca SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 gabrielfu...@suremptec.com.ar http://www.suremptec.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange errors with large vrt
On 10/09/2012 08:45 PM, Even Rouault wrote: Did you check that there was no error or warning reported when building the VRT ? There is no warning from gdalbuiltvrt, is there a flag for a verbose mode? What do you mean by I don't have any data ? Do you mean that if you do an extraction from that VRT, you get no significant data ? If I make a crop with gdal_translate I only have a hillshade from the areas originating from SRTM, but not from the Aster areas. The result of gdal_translate is empty above 61°N. Obviously this could come from the fact I used to distinct step to generate hillshade files for SRTM and then for Aster, but I can't see no differences between them ?? What does gdalinfo report on the generated VRT ? Does it reported extent goes above 60° ? Should be ok: Corner Coordinates: Upper Left (-20037508.316,17822038.826) (180d 0' 0.00W, 83d 0' 0.50N) Lower Left (-20037508.316,-11402298.645) (180d 0' 0.00W, 71d 0' 0.28S) Upper Right (20037428.628,17822038.826) (179d59'57.42E, 83d 0' 0.50N) Lower Right (20037428.628,-11402298.645) (179d59'57.42E, 71d 0' 0.28S) Center ( -39.844, 3209870.091) ( 0d 0' 1.29W, 27d41'21.83N) Maybe someone can see a difference between hillshade2_N58E164.tif and hillshade2_N63E164.tif ? See gdalinfo below, I don't. I don't see any difference... But all the files you provided in the archive are definitely odd : their first band is set to 0. Only the 2nd band (alpha band= has non uniform data. So that might explain what you saw with the huge .vrt This is intended to build a hillshade overlay for webmaps, hence the black + alpha. Also, vrt files and some tiles can be found at http://www.pistes-nordiques.org/download/extract.zip (16MB). No VRT files in that zip. http://www.pistes-nordiques.org/download/small.vrt http://www.pistes-nordiques.org/download/big.vrt Yves ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] [update] Re: Travis CI continuous integration service for GDAL
Le dimanche 07 octobre 2012 11:42:30, Even Rouault a écrit : Hi, Following a recent similar move from MapServer, I've setup an instance of Travis CI, hosted continuous integration service. After each SVN commit in trunk, GDAL is built and the Java, Perl and Python tests are run. Travis CI currently offers Ubuntu 12.04 i386 virtual machines. The GDAL build is configured with almost any possible dependencies to external libraries (see http://trac.osgeo.org/gdal/wiki/Buildbot for the list) You can access to the latest builds here : https://travis-ci.org/#!/rouault/gdal/builds Just a follow-up to inform you that GDAL SVN is now fully mirrored (meaning that it includes all branches and tags) at : https://github.com/OSGeo/gdal (The update script still runs on my PC.) Travis builds are available consequently at : https://travis-ci.org/#!/OSGeo/gdal Both trunk and 1.9 branch benefit from Travis configuration. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
