[gdal-dev] Re: Are these WFS issues worth filing tickets?
Even Rouault even.rouault at mines-paris.org writes: How about having an option -TRUST_GETCAPABILITIES=TRUE and use it as a default value? So number of feature could be examined with resulttype=hits and extents could be taken as they are in the getCapabilities. Or perhaps they could be reported as unknown if reprojecting the lat/lon bounding box feels bad or is inaccurate/impossible? Extents are not always so interesting. I also somehow imagined that. Perhaps you could file a ticket about that, so it can be eventually considered later. After all, such option would not make sense with ogrinfo tool and therefore I will not make a ticket about it. GetCapabilities is sending fixed information about the whole layer and that is unusable if user is making selections with -where, -sql or -spat parameters. In that case the only possibility to get the desired information is to read the features. My next bid is to try to teach the users to avoid unintentionally heavy requests by adding a new paragraph into the WFS driver document page http://gdal.org/ogr/drv_wfs.html Using ogrinfo = Ogrinfo tool tries to apply the spatial and attribute filters from the command line and fetches then data from the WFS service. If no fiters are given this will lead to reading all features from a WFS data source with a GetFeature request. This can be a slow operation. Particularly when ogrinfo is used with the 'all layers' parameter (ogrinfo -al) it will make sequential request for fetching the contents of each feature type from the whole WFS service. When exhaustive layer info is not needed the use of special layers WFSLayerMetadata and WFSGetCapabilities offer a much faster access to WFS service metadata. My last suggestion is to make third special layer or actually set of special layers. It could be named as WFSLayerSchema and it would return the schema that is captured by making a DescribeFeatureType query. Usage might be like ogrinfo WFS:server.com/wfs WFSLayerSchema:[featureType]. Now the only way see the shema is to use the heavy request. Regards, -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Are these WFS issues worth filing tickets?
Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi: Even Rouault even.rouault at mines-paris.org writes: How about having an option -TRUST_GETCAPABILITIES=TRUE and use it as a default value? So number of feature could be examined with resulttype=hits and extents could be taken as they are in the getCapabilities. Or perhaps they could be reported as unknown if reprojecting the lat/lon bounding box feels bad or is inaccurate/impossible? Extents are not always so interesting. I also somehow imagined that. Perhaps you could file a ticket about that, so it can be eventually considered later. After all, such option would not make sense with ogrinfo tool and therefore I will not make a ticket about it. GetCapabilities is sending fixed information about the whole layer and that is unusable if user is making selections with -where, -sql or -spat parameters. In that case the only possibility to get the desired information is to read the features. Well, the GetExtent() API has not a well defined semantics regarding to whether it should take the filters into account or not ( see http://gdal.org/ogr/ogr__api_8h.html#a6c495581900c8301dff91d8cd3ee12f ) and indeed, there is a lot of variations between drivers. So I still believe that the configuration option could make sense. ... but while looking at GetExtent() API more closely, I see that there is a bForce parameter that could be used : If bForce is FALSE, and it would be expensive to establish the extent then OGRERR_FAILURE will be returned indicating that the extent isn't know. If bForce is TRUE then some implementations will actually scan the entire layer once to compute the MBR of all the features in the layer . AFAIR, very few drivers actually check the value of the bForce driver (I cannot quote a single one from my memory which would use it. I should do extensive searching). ogrinfo currently sets bForce = TRUE. An option would be to change the default to FALSE, and add an option to ogrinfo -compute_extent to explicitely set bForce to TRUE if needed. So for the WFS driver, GetExtent(bForce = FALSE) would return a OGRERR_FAILURE, whereas GetExtent(bForce = TRUE) would do the current behaviour. What do you think ? My next bid is to try to teach the users to avoid unintentionally heavy requests by adding a new paragraph into the WFS driver document page http://gdal.org/ogr/drv_wfs.html Using ogrinfo = Ogrinfo tool tries to apply the spatial and attribute filters from the command line and fetches then data from the WFS service. If no fiters are given this will lead to reading all features from a WFS data source with a GetFeature request. This can be a slow operation. Particularly when ogrinfo is used with the 'all layers' parameter (ogrinfo -al) it will make sequential request for fetching the contents of each feature type from the whole WFS service. When exhaustive layer info is not needed the use of special layers WFSLayerMetadata and WFSGetCapabilities offer a much faster access to WFS service metadata. Thanks. Makes sense to document the behaviour of current releases. My last suggestion is to make third special layer or actually set of special layers. It could be named as WFSLayerSchema and it would return the schema that is captured by making a DescribeFeatureType query. Usage might be like ogrinfo WFS:server.com/wfs WFSLayerSchema:[featureType]. Now the only way see the shema is to use the heavy request. I don't know if it would still be usefull if the slowness of GetExtent() is solved. In addition, there are some caveats : * For example, Deegree WFS servers (at least the demo ones) generally return a DescribeFeatureType with a lot of xs:include, but not interesting content. For that you need to downloaded the referenced xsd in the includes. The OGR WFS driver gives up at that point and just tries to establish the layer definition by requesting just one feature. * Sometimes the GML driver isn't smart enough to understand the schema (because it contains nested attributes, or of non-primitive types), so it will also establish the layer definition by requesting just one feature. So the actual layer definition returned by the driver can be a bit (or a lot) different from the one advertized in DescribeFeatureType. (In which case attribute or spatial filtering won't work due to the mismatch ...). WFS administrators : you'd better stick to the GML SF-0 implementation profile ... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Are these WFS issues worth filing tickets?
Even Rouault wrote: Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi: Even Rouault even.rouault at mines-paris.org writes: How about having an option -TRUST_GETCAPABILITIES=TRUE and use it as a default value? So number of feature could be examined with resulttype=hits and extents could be taken as they are in the getCapabilities. Or perhaps they could be reported as unknown if reprojecting the lat/lon bounding box feels bad or is inaccurate/impossible? Extents are not always so interesting. I also somehow imagined that. Perhaps you could file a ticket about that, so it can be eventually considered later. After all, such option would not make sense with ogrinfo tool and therefore I will not make a ticket about it. GetCapabilities is sending fixed information about the whole layer and that is unusable if user is making selections with -where, -sql or -spat parameters. In that case the only possibility to get the desired information is to read the features. Well, the GetExtent() API has not a well defined semantics regarding to whether it should take the filters into account or not ( see http://gdal.org/ogr/ogr__api_8h.html#a6c495581900c8301dff91d8c d3ee12f ) and indeed, there is a lot of variations between drivers. So I still believe that the configuration option could make sense. ... but while looking at GetExtent() API more closely, I see that there is a bForce parameter that could be used : If bForce is FALSE, and it would be expensive to establish the extent then OGRERR_FAILURE will be returned indicating that the extent isn't know. If bForce is TRUE then some implementations will actually scan the entire layer once to compute the MBR of all the features in the layer . AFAIR, very few drivers actually check the value of the bForce driver (I cannot quote a single one from my memory which would use it. I should do extensive searching). ogrinfo currently sets bForce = TRUE. An option would be to change the default to FALSE, and add an option to ogrinfo -compute_extent to explicitely set bForce to TRUE if needed. So for the WFS driver, GetExtent(bForce = FALSE) would return a OGRERR_FAILURE, whereas GetExtent(bForce = TRUE) would do the current behaviour. What do you think ? I think I am going to count on you. About extent computing, it might be good to check how bForce behaves with Oracle driver. Selecting aggregate MBR from Oracle is very heavy. My next bid is to try to teach the users to avoid unintentionally heavy requests by adding a new paragraph into the WFS driver document page http://gdal.org/ogr/drv_wfs.html Using ogrinfo = Ogrinfo tool tries to apply the spatial and attribute filters from the command line and fetches then data from the WFS service. If no fiters are given this will lead to reading all features from a WFS data source with a GetFeature request. This can be a slow operation. Particularly when ogrinfo is used with the 'all layers' parameter (ogrinfo -al) it will make sequential request for fetching the contents of each feature type from the whole WFS service. When exhaustive layer info is not needed the use of special layers WFSLayerMetadata and WFSGetCapabilities offer a much faster access to WFS service metadata. Thanks. Makes sense to document the behaviour of current releases. My last suggestion is to make third special layer or actually set of special layers. It could be named as WFSLayerSchema and it would return the schema that is captured by making a DescribeFeatureType query. Usage might be like ogrinfo WFS:server.com/wfs WFSLayerSchema:[featureType]. Now the only way see the shema is to use the heavy request. I don't know if it would still be usefull if the slowness of GetExtent() is solved. In addition, there are some caveats : * For example, Deegree WFS servers (at least the demo ones) generally return a DescribeFeatureType with a lot of xs:include, but not interesting content. For that you need to downloaded the referenced xsd in the includes. The OGR WFS driver gives up at that point and just tries to establish the layer definition by requesting just one feature. * Sometimes the GML driver isn't smart enough to understand the schema (because it contains nested attributes, or of non-primitive types), so it will also establish the layer definition by requesting just one feature. So the actual layer definition returned by the driver can be a bit (or a lot) different from the one advertized in DescribeFeatureType. (In which case attribute or spatial filtering won't work due to the mismatch ...). WFS administrators : you'd better stick to the GML SF-0 implementation profile ... I agree, I totally forgot both the deegree server behaviour and complicated application schemas. But is it ever safe to guess the schema by
Re: [gdal-dev] Re: Are these WFS issues worth filing tickets?
But is it ever safe to guess the schema by investigating just the first feature? If the attribute is not compulsory in the schema and the value happens to be empty then it is not included at all in the GML of the first feature. Doesn't this mean that GML driver creates a schema without that attribute even the following features may have values for it? No, it is not completely reliable and you have perfectly identified the cases where it doesn't work. The attributes that are not found in the first feature will be ignored if found in the following features. The alternative would be ... to downloaded the full GetFeature document ;-) (or better, manage to write a better XSD parser) -Jukka Rahkonen-___ 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
[gdal-dev] Longitude and latitude raster bands
Hi, For datasets with only GCPs for geolocation, is there any convenient and efficient method to extract latitude and longitude values as arrays of same size as the raster bands, using the Python API? And similarly: is there an efficient method to return full arrays of the azimuth direction, e.g. defined as 0 for pixels where north is up (as it would always be in a lon-lat or Mercator projection). This angle is relevant e.g. when one want to know the sensor look direction for satellite images. Best regards from Knut-Frode ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] PCT Pallete
How you can create your own pallet for the tool rgb2pct from existing rgb image. What kind of technics are existing in order to define such a pallete? --Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PCT Pallete
Nikos, The easiest way to create your own palette is described in the documentation of the script[1]. You can use any raster file with a palette as a source of palette. In the example in the script's documentation, a dummy VRT file with a color palette is created and used. [1]: http://www.gdal.org/rgb2pct.html On Tue, Jan 10, 2012 at 11:44 PM, Nikolaos Hatzopoulos nhat...@gmail.comwrote: How you can create your own pallet for the tool rgb2pct from existing rgb image. What kind of technics are existing in order to define such a pallete? --Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Compiling fails on Debian
Hi Even, a verbose and helpful answer, as always. Point 3), the wrong symlink, seems to be my problem too. I am in the course of investigating how to resolve the problem. I just wanted to thank you for your help so far ... Frank Am 09.01.2012 13:44, schrieb Even Rouault: Frank, This looks like if the linking of the GDAL shared library was using the static version of libstdc++ (the message recompile with -fPIC is for libstdc++, not GDAL...) . A bit of googling shows that this error has been encountered with various software packages. Several tracks : 1) https://bugs.archlinux.org/task/14268 suggest to check that there is no /usr/lib/libstdc++.la around. If there's one, rename it, and try again. 2) Other links would suggest that /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a library was incorrectly built, and not appropriate for being used by shared libraries. 3) http://code.google.com/p/staff/issues/detail?id=150 is also interesting : Very strange, but why g++ tries to link libstdc++ staticaly? That was the key question. With the help of strace (my favorite tool) I figured out that g++ fell back to the static lib (/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a) after getting an error when trying to access the shared lib (/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.so). The shared lib was a broken symlink. The link apparently broke when I upgraded libstdc++6 to 4.6.1-4 without upgrading libstdc++6-4.4-dev at the same time. Sorry to have bothered you with this... So perhaps start by upgrading your libstdc++6-4.4-dev package ? 4) If none of the above works and it is libtool related as the above would suggest, perhaps you could also try adding --without-libtool to your GDAL ./configure command line. The experience shows that it sometimes helps, but I'm not positive it will be the case here. Hi, I try to compile gdal 1.9.0RC2 on my Debian machine brfr@devel:~/gdal$ uname -ra Linux devel 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux but make exits with an error 2. The last messages before exiting: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libgdal.la] Fehler 1 make[1]: Leaving directory `/home/brfr/gdal/gdal-1.9.0' make: *** [check-lib] Fehler 2 I tried already with the fPIC flag brfr@devel:~/gdal$ export CXXFLAGS=-fPIC brfr@devel:~/gdal$ ./configure --with-python --with-geos=yes --enable-debug brfr@devel:~/gdal$ make but without success Any hints? Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
