subject:"\[gdal\-dev\] WFS driver"

Re: [gdal-dev] WFS driver

2021-10-08 Thread Richard Duivenvoorde

On 10/7/21 1:46 PM, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> If you are asking the same question in gis.stackexchange please wait some 
> minutes if somebody happens to answer you before sending mail to gdal-dev. Or 
> vise versa. Crossposting in the long run will not help you to get answers 
> faster.

Well, it helped to get my attention ;-) I'm not so often looking at 
gis.stackexchange

But this USER question (this is not a dev question) I try to answer there now 
with some examples:

https://gis.stackexchange.com/questions/413390/

Hope this helps.

Regards,

Richard Duivenvoorde
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver

2021-10-07 Thread Rahkonen Jukka (MML)

Hi,

If you are asking the same question in gis.stackexchange please wait some 
minutes if somebody happens to answer you before sending mail to gdal-dev. Or 
vise versa. Crossposting in the long run will not help you to get answers 
faster.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Mohammed 
Aljezawi
Lähetetty: torstai 7. lokakuuta 2021 13.22
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] WFS driver

Hi,
I am using gdal to convert from WFS to geopackge, everything is working fine 
but I need to change the name of each table before or after converting to 
GeoPackage, because the layer name has a special charachart that in my 
application it's not working.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WFS driver

2021-10-07 Thread Mohammed Aljezawi

Hi,
I am using gdal to convert from WFS to geopackge, everything is
working fine but I need to change the name of each table before or after
converting to GeoPackage, because the layer name has a special charachart
that in my application it's not working.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver and GML application schema

2017-03-07 Thread Even Rouault

On mardi 7 mars 2017 09:57:26 CET Rahkonen Jukka (MML) wrote:
> Hi,
> 
> What if a WFS server is returning GML that has complex schema, does GDAL
> know to open the response as GML application schema data automatically or
> with some open option?  I  ask because I can see "succeeds as GML" in the
> debug log:

The WFS driver only uses internally the classic GML driver that supports 
(mostly) simple 
schemas. When parsing a GetFeature response the GML driver analyzes the 
schemaLocation 
attribute of the top element and tries to download the schema pointed by it and 
analyze it 
(actually when it is triggered by the WFS driver which has already downloaded 
the schema, 
the WFS driver already creates the .xsd in-memory file, so the GML driver 
doesn't need to 
download it. Implementation detail...) But this analysis only succeeds if the 
schema is simple, 
so hee it fails hence the generating .gfs file message.

I've no thought deeply how the WFS driver could use the GMLAS driver, but that 
would be a 
fair amount of work. So currently your best option when the WFS server is 
serving complex 
features is to download the GetFeature response and use it explicitely with the 
GMLAS 
driver.

Even

> 
> HTTP:
> Fetch(https://opaskartta.turku.fi/TeklaOGCWeb/WFS.ashx?SERVICE=WFS&VERSION=
> 1.0.0&REQUEST=DescribeFeatureType&typeName=akaava:Kaavayksikko) GML:
> Generating /vsimem/tempwfs_034A8DC0/file.gfs file, ignoring
> /vsimem/tmp_gml_xsd_03B73E80.xsd GDAL:
> GDALOpen(/vsimem/tempwfs_034A8DC0/file.gml, this=03B73E80)
> succeeds as GML.
> 
> 
> -Jukka Rahkonen-

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WFS driver and GML application schema

2017-03-07 Thread Rahkonen Jukka (MML)

Hi,

What if a WFS server is returning GML that has complex schema, does GDAL know 
to open the response as GML application schema data automatically or with some 
open option?  I  ask because I can see "succeeds as GML" in the debug log:

HTTP: 
Fetch(https://opaskartta.turku.fi/TeklaOGCWeb/WFS.ashx?SERVICE=WFS&VERSION=1.0.0&REQUEST=DescribeFeatureType&typeName=akaava:Kaavayksikko)
GML: Generating /vsimem/tempwfs_034A8DC0/file.gfs file, ignoring 
/vsimem/tmp_gml_xsd_03B73E80.xsd
GDAL: GDALOpen(/vsimem/tempwfs_034A8DC0/file.gml, 
this=03B73E80) succeeds as GML.


-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-10-19 Thread Odd Ragnar Lydersen

Thanks for the clarification about the axis order, which differs between the 
two versions of WFS.
That explains a lot, and first tests in my code is looking good.

Those pitfalls, are hard to see sometimes.

>Odd-Ragnar< 

-Opprinnelig melding-
Fra: Even Rouault [mailto:even.roua...@spatialys.com] 
Sendt: onsdag 19. oktober 2016 15.55
Til: Odd Ragnar Lydersen 
Kopi: gdal-dev@lists.osgeo.org
Emne: Re: SV: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

Le mercredi 19 octobre 2016 15:17:52, Odd Ragnar Lydersen a écrit :
> Now I have come around to test this a bit more.
> 
> 1) I tried the same as you did, only for wfs v. 1.1.0
> 
> ogrinfo -ro
> "WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1"; 
> continents -al  -spat 0 45 15 50 INFO: Open of 
> `WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1'
> using driver `WFS' successful.
> Metadata:
>   ABSTRACT=This demonstration server showcases MapServer
> (www.mapserver.org) and its OGC support PROVIDER_NAME=Gateway Geomatics
>   TITLE=WMS Demo Server for MapServer
> 
> Layer name: continents
> Metadata:
>   TITLE=World continents
> Geometry: Unknown (any)
> Feature Count: 0
> ...
> 
> Not working in version 1.1.0.

Add "-oo CONSIDER_EPSG_AS_URN=YES". MapServer WFS 1.1 returns srsName in 
EPSG:XXX form even though it honours EPSG axix order (ie lat, long). But the 
OGR GML & WFS readers interpret "EPSG:" as the old GIS convention (long, 
lat order). So here it will let the coordinates in that lat, long order, but 
when evaluating the spatial filter on client side, it will discard the feature 
as the coordinates are in the wrong order.
Specifying CONSIDER_EPSG_AS_URN=YES will instruct them to interpret EPSG: 
as if it was urn:ogc:def:crs:EPSG::

Disclaimer: I'm not responsible for the axis order mess :-)

> 
> 2) I add the spatial filter to the URL, using BBOX.
> 
> ogrinfo -ro
> "WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1
> &BBO X=0,45,15,50"  continents -al INFO: Open of 
> `WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1
> &BBO X=0,45,15,50' using driver `WFS' successful.
> Metadata:
>   ABSTRACT=This demonstration server showcases MapServer
> (www.mapserver.org) and its OGC support PROVIDER_NAME=Gateway Geomatics
>   TITLE=WMS Demo Server for MapServer
> 
> Layer name: continents
> Metadata:
>   TITLE=World continents
> Geometry: Unknown (any)
> Feature Count: 1
> ...
> 
> Working in version 1.1.0, when adding BBOX to URL.

Works somehow, but note that the coordinate order is lat,long. Related to the 
previous point.

> 
> 3) Then I tested this out in our application, and all is well if I 
> read GDAL:WFS without really using the C++ api, and just setting up 
> the config file with the correct URL-parameters. Both version 1.0.0 and 1.1.0 
> works.
> 
> Shouldn't this work just as well using the C++ API calls, to set up 
> the spatial constraints, and maxfeatures? Now I'm rather editing the 
> URL to get the result I want, and that is OK, but a bit awkward and 
> cumbersome.

Not sure to understand, but perhaps related to the above issue.

--
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

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-10-19 Thread Even Rouault

Le mercredi 19 octobre 2016 15:17:52, Odd Ragnar Lydersen a écrit :
> Now I have come around to test this a bit more.
> 
> 1) I tried the same as you did, only for wfs v. 1.1.0
> 
> ogrinfo -ro
> "WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1"; 
> continents -al  -spat 0 45 15 50 INFO: Open of
> `WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1'
> using driver `WFS' successful.
> Metadata:
>   ABSTRACT=This demonstration server showcases MapServer
> (www.mapserver.org) and its OGC support PROVIDER_NAME=Gateway Geomatics
>   TITLE=WMS Demo Server for MapServer
> 
> Layer name: continents
> Metadata:
>   TITLE=World continents
> Geometry: Unknown (any)
> Feature Count: 0
> ...
> 
> Not working in version 1.1.0.

Add "-oo CONSIDER_EPSG_AS_URN=YES". MapServer WFS 1.1 returns srsName in 
EPSG:XXX form even though it honours EPSG axix order (ie lat, long). But the 
OGR GML & WFS readers interpret "EPSG:" as the old GIS convention (long, 
lat order). So here it will let the coordinates in that lat, long order, but 
when evaluating the spatial filter on client side, it will discard the feature 
as the coordinates are in the wrong order.
Specifying CONSIDER_EPSG_AS_URN=YES will instruct them to interpret EPSG: 
as if it was urn:ogc:def:crs:EPSG::

Disclaimer: I'm not responsible for the axis order mess :-)

> 
> 2) I add the spatial filter to the URL, using BBOX.
> 
> ogrinfo -ro
> "WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1&BBO
> X=0,45,15,50"  continents -al INFO: Open of
> `WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1&BBO
> X=0,45,15,50' using driver `WFS' successful.
> Metadata:
>   ABSTRACT=This demonstration server showcases MapServer
> (www.mapserver.org) and its OGC support PROVIDER_NAME=Gateway Geomatics
>   TITLE=WMS Demo Server for MapServer
> 
> Layer name: continents
> Metadata:
>   TITLE=World continents
> Geometry: Unknown (any)
> Feature Count: 1
> ...
> 
> Working in version 1.1.0, when adding BBOX to URL.

Works somehow, but note that the coordinate order is lat,long. Related to the 
previous point.

> 
> 3) Then I tested this out in our application, and all is well if I read
> GDAL:WFS without really using the C++ api, and just setting up the config
> file with the correct URL-parameters. Both version 1.0.0 and 1.1.0 works.
> 
> Shouldn't this work just as well using the C++ API calls, to set up the
> spatial constraints, and maxfeatures? Now I'm rather editing the URL to
> get the result I want, and that is OK, but a bit awkward and cumbersome.

Not sure to understand, but perhaps related to the above issue.

-- 
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

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-10-19 Thread Odd Ragnar Lydersen

Now I have come around to test this a bit more.
 
1) I tried the same as you did, only for wfs v. 1.1.0

ogrinfo -ro 
"WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1";  
continents -al  -spat 0 45 15 50
INFO: Open of 
`WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=This demonstration server showcases MapServer (www.mapserver.org) 
and its OGC support
  PROVIDER_NAME=Gateway Geomatics
  TITLE=WMS Demo Server for MapServer

Layer name: continents
Metadata:
  TITLE=World continents
Geometry: Unknown (any)
Feature Count: 0
...

Not working in version 1.1.0.

2) I add the spatial filter to the URL, using BBOX.

ogrinfo -ro 
"WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1&BBOX=0,45,15,50";
  continents -al
INFO: Open of 
`WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.1.0&MAXFEATURES=1&BBOX=0,45,15,50'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=This demonstration server showcases MapServer (www.mapserver.org) 
and its OGC support
  PROVIDER_NAME=Gateway Geomatics
  TITLE=WMS Demo Server for MapServer

Layer name: continents
Metadata:
  TITLE=World continents
Geometry: Unknown (any)
Feature Count: 1
...

Working in version 1.1.0, when adding BBOX to URL.

3) Then I tested this out in our application, and all is well if I read 
GDAL:WFS without really using the C++ api, and just setting up the config file 
with the correct URL-parameters. Both version 1.0.0 and 1.1.0 works.

Shouldn't this work just as well using the C++ API calls, to set up the spatial 
constraints, and maxfeatures?
Now I'm rather editing the URL to get the result I want, and that is OK, but a 
bit awkward and cumbersome.

>Odd-Ragnar<

-Opprinnelig melding-
Fra: Even Rouault [mailto:even.roua...@spatialys.com] 
Sendt: torsdag 29. september 2016 11.20
Til: gdal-dev@lists.osgeo.org
Kopi: Odd Ragnar Lydersen 
Emne: Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

Le jeudi 29 septembre 2016 10:06:12, Odd Ragnar Lydersen a écrit :
> So I have tried to dig a bit more into this, and I have noticed a few 
> things.
> 
> 
> 1)  I set MAXFEATURES=60 in the url
> 
> 2)  I select the layer I want to work with, let's call it MyLayer.
> 
> 3)  I call SetSpatialFilterRect() on the MyLayer and set it to a small
> area containing 11 points.
> 
> 4)  I call GetFeatureCount() on MyLayer, and then I get 60 features
> returned, even though I know it should be spatially bound to an area 
> containing only 11 features.
> 
> 5)  Then I should be iterating through all the features, using
> GetNextFeature(), but no features are read.
> 
> In 4), the result from GetFeatureCount(), should have been 11.
> In 5), I should have been able to read the expected 11 features.
> 

The WFS driver has quite a bunch of optimizations (and workarounds for buggy 
implementations), which are as many doors for more or less subtle bugs, but in 
my below testing, that seems to work :

$ python
>>> from osgeo import ogr
>>> ds = 
>>> ogr.Open('WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MA
>>> XFEATURES=1') lyr = ds.GetLayerByName('continents')
>>> lyr.SetSpatialFilterRect(0,45,15,50)
>>> print(lyr.GetFeatureCount())
1
>>> f = lyr.GetNextFeature()
>>> print(f['NA2DESC'])
'Italy'
>>> f = lyr.GetNextFeature()
>>> print(f)
None

or from the command line :
$ ogrinfo -ro 
"WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1";  
continents -al  -spat 0 45 15 50
INFO: Open of 
`WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=This demonstration server showcases MapServer (www.mapserver.org) 
and its OGC support
  TITLE=WMS Demo Server for MapServer

Layer name: continents
Metadata:
  TITLE=World continents
Geometry: Unknown (any)
Feature Count: 1
Extent: (13.427750, 45.697224) - (13.439472, 45.711639) Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Geometry Column = msGeometry
gml_id: String (0.0) NOT NULL
NA2DESC: String (0.0)
NA3DESC: String (0.0)
OGRFeature(continents):22518
  gml_id (String) = continents.22518
  NA2DESC (String) = Italy
  NA3DESC (String) = Europe

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-09-29 Thread Odd Ragnar Lydersen

So it seems I have to do a bit more testing then.
Perhaps it's the server I'm accessing which is buggy then.

I'll have a go with the testserver you're using, and compare.

Thanks for the answer.

>Odd-Ragnar<

-Opprinnelig melding-
Fra: Even Rouault [mailto:even.roua...@spatialys.com] 
Sendt: torsdag 29. september 2016 11.20
Til: gdal-dev@lists.osgeo.org
Kopi: Odd Ragnar Lydersen 
Emne: Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

Le jeudi 29 septembre 2016 10:06:12, Odd Ragnar Lydersen a écrit :
> So I have tried to dig a bit more into this, and I have noticed a few 
> things.
> 
> 
> 1)  I set MAXFEATURES=60 in the url
> 
> 2)  I select the layer I want to work with, let's call it MyLayer.
> 
> 3)  I call SetSpatialFilterRect() on the MyLayer and set it to a small
> area containing 11 points.
> 
> 4)  I call GetFeatureCount() on MyLayer, and then I get 60 features
> returned, even though I know it should be spatially bound to an area 
> containing only 11 features.
> 
> 5)  Then I should be iterating through all the features, using
> GetNextFeature(), but no features are read.
> 
> In 4), the result from GetFeatureCount(), should have been 11.
> In 5), I should have been able to read the expected 11 features.
> 

The WFS driver has quite a bunch of optimizations (and workarounds for buggy 
implementations), which are as many doors for more or less subtle bugs, but in 
my below testing, that seems to work :

$ python
>>> from osgeo import ogr
>>> ds = 
>>> ogr.Open('WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MA
>>> XFEATURES=1') lyr = ds.GetLayerByName('continents')
>>> lyr.SetSpatialFilterRect(0,45,15,50)
>>> print(lyr.GetFeatureCount())
1
>>> f = lyr.GetNextFeature()
>>> print(f['NA2DESC'])
'Italy'
>>> f = lyr.GetNextFeature()
>>> print(f)
None

or from the command line :
$ ogrinfo -ro 
"WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1";  
continents -al  -spat 0 45 15 50
INFO: Open of 
`WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=This demonstration server showcases MapServer (www.mapserver.org) 
and its OGC support
  TITLE=WMS Demo Server for MapServer

Layer name: continents
Metadata:
  TITLE=World continents
Geometry: Unknown (any)
Feature Count: 1
Extent: (13.427750, 45.697224) - (13.439472, 45.711639) Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Geometry Column = msGeometry
gml_id: String (0.0) NOT NULL
NA2DESC: String (0.0)
NA3DESC: String (0.0)
OGRFeature(continents):22518
  gml_id (String) = continents.22518
  NA2DESC (String) = Italy
  NA3DESC (String) = Europe
  POLYGON ((13.437944 45.708195,13.438861 45.706806,13.439472 
45.705387,13.438694 45.702862,13.436277 45.700832,13.432834 45.697224,13.431194 
45.697472,13.430611
45.699085,13.432083 45.702999,13.432167 45.704613,13.430305 45.707443,13.42775 
45.709583,13.4285 45.711639,13.43275 45.710167,13.437944 45.708195))





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

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-09-29 Thread Even Rouault

Le jeudi 29 septembre 2016 10:06:12, Odd Ragnar Lydersen a écrit :
> So I have tried to dig a bit more into this, and I have noticed a few
> things.
> 
> 
> 1)  I set MAXFEATURES=60 in the url
> 
> 2)  I select the layer I want to work with, let's call it MyLayer.
> 
> 3)  I call SetSpatialFilterRect() on the MyLayer and set it to a small
> area containing 11 points.
> 
> 4)  I call GetFeatureCount() on MyLayer, and then I get 60 features
> returned, even though I know it should be spatially bound to an area
> containing only 11 features.
> 
> 5)  Then I should be iterating through all the features, using
> GetNextFeature(), but no features are read.
> 
> In 4), the result from GetFeatureCount(), should have been 11.
> In 5), I should have been able to read the expected 11 features.
> 

The WFS driver has quite a bunch of optimizations (and workarounds for buggy 
implementations),
which are as many doors for more or less subtle bugs, but in my below testing, 
that seems to work :

$ python
>>> from osgeo import ogr
>>> ds = 
>>> ogr.Open('WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1')
>>> lyr = ds.GetLayerByName('continents')
>>> lyr.SetSpatialFilterRect(0,45,15,50)
>>> print(lyr.GetFeatureCount())
1
>>> f = lyr.GetNextFeature()
>>> print(f['NA2DESC'])
'Italy'
>>> f = lyr.GetNextFeature()
>>> print(f)
None

or from the command line :
$ ogrinfo -ro 
"WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1";  
continents -al  -spat 0 45 15 50
INFO: Open of 
`WFS:http://demo.mapserver.org/cgi-bin/wfs?VERSION=1.0.0&MAXFEATURES=1'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=This demonstration server showcases MapServer (www.mapserver.org) 
and its OGC support
  TITLE=WMS Demo Server for MapServer

Layer name: continents
Metadata:
  TITLE=World continents
Geometry: Unknown (any)
Feature Count: 1
Extent: (13.427750, 45.697224) - (13.439472, 45.711639)
Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Geometry Column = msGeometry
gml_id: String (0.0) NOT NULL
NA2DESC: String (0.0)
NA3DESC: String (0.0)
OGRFeature(continents):22518
  gml_id (String) = continents.22518
  NA2DESC (String) = Italy
  NA3DESC (String) = Europe
  POLYGON ((13.437944 45.708195,13.438861 45.706806,13.439472 
45.705387,13.438694 45.702862,13.436277 45.700832,13.432834 45.697224,13.431194 
45.697472,13.430611 
45.699085,13.432083 45.702999,13.432167 45.704613,13.430305 45.707443,13.42775 
45.709583,13.4285 45.711639,13.43275 45.710167,13.437944 45.708195))





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

Re: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

2016-09-29 Thread Odd Ragnar Lydersen

So I have tried to dig a bit more into this, and I have noticed a few things.


1)  I set MAXFEATURES=60 in the url

2)  I select the layer I want to work with, let's call it MyLayer.

3)  I call SetSpatialFilterRect() on the MyLayer and set it to a small area 
containing 11 points.

4)  I call GetFeatureCount() on MyLayer, and then I get 60 features 
returned, even though I know it should be spatially bound to an area containing 
only 11 features.

5)  Then I should be iterating through all the features, using 
GetNextFeature(), but no features are read.

In 4), the result from GetFeatureCount(), should have been 11.
In 5), I should have been able to read the expected 11 features.


>From the code in ogrwfslayer.cpp in GIntBig 
>OGRWFSLayer::ExecuteGetFeatureResultTypeHits():

/* Hum, 
http://deegree3-testing.deegree.org:80/deegree-inspire-node/services?MAXFEATURES=10&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ad:Address&OUTPUTFORMAT=text/xml;%20subtype=gml/3.2.1&RESULTTYPE=hits
 */
/* returns more than MAXFEATURES features... So truncate to MAXFEATURES */
CPLString osMaxFeatures = CPLURLGetValue(osURL, atoi(poDS->GetVersion()) >= 2 ? 
"COUNT" : "MAXFEATURES");

Does this mean that the use of MAXFEATURES isn't working?
Have not tested this on WFS version 2.x.
Can anyone confirm if it's working in that version?
It would be nice to know.

We may decide to have a go at fixing this in the future, but for now we're just 
going to disable the use of MAXFEATURES, and just use, SetSpatialFilterRect(), 
to restrain the number of features returned from a layer.

>Odd-Ragnar<

Fra: Odd Ragnar Lydersen [mailto:odd-ragnar.lyder...@powel.no]
Sendt: onsdag 28. september 2016 14.10
Til: gdal-dev@lists.osgeo.org
Emne: [gdal-dev] WFS driver bug2 - MAXFEATURES not working

When I use the WFS driver (GDAL 2.1.1) for version 1.0.0 or 1.1.0, and add 
MAXFEATURES to the url, then I get zero features retuned, from the service.
If I drop MAXFEATURES in the request-url, then I get all the features in my 
bounding box returned from the service.

This is a password protected service, could it be related to my "WFS driver 
bug1"?

Med vennlig hilsen
Odd-Ragnar Lydersen
System Developer

Powel AS Storgata 27B, Pb 369, N-4349 Bryne, NORWAY
Email: odd-ragnar.lyder...@powel.no<mailto:odd-ragnar.lyder...@powel.no>
www.powel.no<http://www.powel.com/>
[cid:image002.jpg@01CDD1F7.F470C190]<http://www.powel.no/en>[cid:image004.jpg@01CDD1F7.F470C190]<https://www.facebook.com/pages/Powel/350917775700>[cid:image006.jpg@01CDD1F7.F470C190]<http://www.linkedin.com/company/powel-as>

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver bug1

2016-09-28 Thread Even Rouault

Le mercredi 28 septembre 2016 14:00:36, Odd Ragnar Lydersen a écrit :
> When I'm using the WFS driver for version 1.0.0, or version 1.1.0 then I
> get some error messages back from GDAL, when the service is password
> protected. I have not tested this for version 2.x.
> 
> Here is what I have found out:
> 
> 1)  Calls to CPLHTTPFetch() from OGRWFSDataSource::HTTPFetch() is sent
> with UserPwd in papszOptions parameter.
> 
> 2)  Calls to CPLHTTPFetch() from OGRGMLDataSource::Open() is sent
> without UserPwd in papszOptions parameter, in fact the calls from the GML
> driver is always called with the parameter set to NULL .
> 
> Even though I get these errors, I'm still able to read features from the
> service.

The call to CPLHTTPFetch() in the GML driver is to retrieve the XSD from the 
schemaLocation attribute. 
If the driver doesn't manage to retrieve the schema, then it guesses it, which 
explains why this still works despite the error.

> 
> But why are the calls in the GML driver, (on behalf of the WFS driver),
> made without UserPwd in papszOptions parameter?

Because this hasn't been yet implemented. Patch welcome. This would involve 
adding new open options to the GML driver and set them in the WFS driver.

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] WFS driver bug2 - MAXFEATURES not working

2016-09-28 Thread Odd Ragnar Lydersen

When I use the WFS driver (GDAL 2.1.1) for version 1.0.0 or 1.1.0, and add 
MAXFEATURES to the url, then I get zero features retuned, from the service.
If I drop MAXFEATURES in the request-url, then I get all the features in my 
bounding box returned from the service.

This is a password protected service, could it be related to my "WFS driver 
bug1"?

Med vennlig hilsen
Odd-Ragnar Lydersen
System Developer

Powel AS Storgata 27B, Pb 369, N-4349 Bryne, NORWAY
Email: odd-ragnar.lyder...@powel.no
www.powel.no
[cid:image002.jpg@01CDD1F7.F470C190][cid:image004.jpg@01CDD1F7.F470C190][cid:image006.jpg@01CDD1F7.F470C190]

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WFS driver bug1

2016-09-28 Thread Odd Ragnar Lydersen

When I'm using the WFS driver for version 1.0.0, or version 1.1.0 then I get 
some error messages back from GDAL, when the service is password protected.
I have not tested this for version 2.x.

Here is what I have found out:

1)  Calls to CPLHTTPFetch() from OGRWFSDataSource::HTTPFetch() is sent with 
UserPwd in papszOptions parameter.

2)  Calls to CPLHTTPFetch() from OGRGMLDataSource::Open() is sent without 
UserPwd in papszOptions parameter,
in fact the calls from the GML driver is always called with the parameter set 
to NULL .

Even though I get these errors, I'm still able to read features from the 
service.

But why are the calls in the GML driver, (on behalf of the WFS driver), made 
without UserPwd in papszOptions parameter?

I have attached some output from the calls tack, so you can see which calls are 
causing this behaviour.


Best regards
Odd-Ragnar Lydersen
System Developer

Powel AS Storgata 27B, Pb 369, N-4349 Bryne, NORWAY
Email: odd-ragnar.lyder...@powel.no
www.powel.no
[cid:image002.jpg@01CDD1F7.F470C190][cid:image004.jpg@01CDD1F7.F470C190][cid:image006.jpg@01CDD1F7.F470C190]


Call stack for calls without uerpasswd:
4>  gdal211.dll!CPLHTTPFetch(const char * pszURL, char * * papszOptions) 
Line 322   C++
gdal211.dll!OGRGMLDataSource::Open(GDALOpenInfo * poOpenInfo) Line 943  
C++
gdal211.dll!OGRGMLDriverOpen(GDALOpenInfo * poOpenInfo) Line 110
C++
gdal211.dll!GDALOpenEx(const char * pszFilename, unsigned int 
nOpenFlags, const char * const * papszAllowedDrivers, const char * const * 
papszOpenOptions, const char * const * papszSiblingFiles) Line 2762C++
gdal211.dll!OGRWFSLayer::FetchGetFeature(int nRequestMaxFeatures) Line 
1003 C++
gdal211.dll!OGRWFSLayer::BuildLayerDefn(OGRFeatureDefn * poSrcFDefn) 
Line 1083  C++
gdal211.dll!OGRWFSLayer::GetLayerDefn() Line 1063   C++
gdal211.dll!OGRLayer::GetSpatialRef() Line 1034 C++

>   gdal211.dll!CPLHTTPFetch(const char * pszURL, char * * papszOptions) 
> Line 322   C++
gdal211.dll!OGRGMLDataSource::Open(GDALOpenInfo * poOpenInfo) Line 943  
C++
gdal211.dll!OGRGMLDriverOpen(GDALOpenInfo * poOpenInfo) Line 110
C++
gdal211.dll!GDALOpenEx(const char * pszFilename, unsigned int 
nOpenFlags, const char * const * papszAllowedDrivers, const char * const * 
papszOpenOptions, const char * const * papszSiblingFiles) Line 2762C++
gdal211.dll!OGRWFSLayer::FetchGetFeature(int nRequestMaxFeatures) Line 
1003 C++
gdal211.dll!OGRWFSLayer::GetNextFeature() Line 1193 C++

Call stack for successful calls with userpasswd:
1>  gdal211.dll!CPLHTTPFetch(const char * pszURL, char * * papszOptions) 
Line 324   C++
gdal211.dll!OGRWFSDataSource::HTTPFetch(const char * pszURL, char * * 
papszOptions) Line 2058   C++
gdal211.dll!OGRWFSDataSource::LoadMultipleLayerDefn(const char * 
pszLayerName, char * pszNS, char * pszNSVal) Line 1712 C++
gdal211.dll!OGRWFSLayer::GetLayerDefn() Line 1059   C++
gdal211.dll!OGRLayer::GetSpatialRef() Line 1034 C++

2>  gdal211.dll!CPLHTTPFetch(const char * pszURL, char * * papszOptions) 
Line 324   C++
gdal211.dll!OGRWFSDataSource::HTTPFetch(const char * pszURL, char * * 
papszOptions) Line 2058   C++
gdal211.dll!OGRWFSLayer::DescribeFeatureType() Line 230 C++
gdal211.dll!OGRWFSLayer::BuildLayerDefn(OGRFeatureDefn * poSrcFDefn) 
Line 1080  C++
gdal211.dll!OGRWFSLayer::GetLayerDefn() Line 1063   C++
gdal211.dll!OGRLayer::GetSpatialRef() Line 1034 C++

3>  gdal211.dll!CPLHTTPFetch(const char * pszURL, char * * papszOptions) 
Line 324   C++
gdal211.dll!OGRWFSDataSource::HTTPFetch(const char * pszURL, char * * 
papszOptions) Line 2058   C++
gdal211.dll!OGRWFSLayer::FetchGetFeature(int nRequestMaxFeatures) Line 
811  C++
gdal211.dll!OGRWFSLayer::BuildLayerDefn(OGRFeatureDefn * poSrcFDefn) 
Line 1083  C++
gdal211.dll!OGRWFSLayer::GetLayerDefn() Line 1063   C++
gdal211.dll!OGRLayer::GetSpatialRef() Line 1034 C++
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WFS driver - HTTP 401 authentication error message

2016-09-15 Thread Odd Ragnar Lydersen

Hello, I'm experiencing some warnings in GDAL 2.1 and error messages (HTTP 401) 
from the server.

In I'm getting some unwanted results.
However I am able to read features from the server, but I wonder why these 
errors occur, and if I'm not getting all the information I should have gotten 
if this error did not occur.

I have stepped into CPLXMLNode *CPLParseXMLString( const char *pszString )
Before the HTTP error, *pszString,  is this:



http://xml.nls.fi/ktjkiiwfs/2010/02"; 
useGlobalSRSName="true">
http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/KiinteistorajanSijaintitiedot.xsd"/>
http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/palstanTunnuspisteenSijaintitiedot.xsd"/>
http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/RekisteriyksikonTietoja.xsd"/>
http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/PalstanTietoja.xsd"/>


...



And the next call to the same function I get the error, and *pszString,  is 
this:




Error 401--Unauthorized




Error 401--Unauthorized


From 
RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.2 401 Unauthorized
The request requires user authentication. 
The response MUST include a WWW-Authenticate header field (section 14.46) 
containing a challenge applicable to the requested resource. The client MAY 
repeat the request with a suitable Authorization header field (section 14.8). 
If the request already included Authorization credentials, then the 401 
response indicates that authorization has been refused for those credentials. 
If the 401 response contains the same challenge as the prior response, and the 
user agent has already attempted authentication at least once, then the user 
SHOULD be presented the entity that was given in the response, since that 
entity MAY include relevant diagnostic information. HTTP access authentication 
is explained in section 11.






Could it be that the authentication parameter is not sendt in the response call 
to the server in between these two answers?
I can see that there is a call to CPLHTTPResult *CPLHTTPFetch( const char 
*pszURL, char **papszOptions ) , without any content in **papszOptions.
In other calls I can see that the UserPwd is sendt in the **papszOptions 
variable.

Odd-Ragnar Lydersen
System Developer

Email: odd-ragnar.lyder...@powel.no
www.powel.no
[cid:image002.jpg@01CDD1F7.F470C190][cid:image004.jpg@01CDD1F7.F470C190][cid:image006.jpg@01CDD1F7.F470C190]

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver and filtering

2014-06-07 Thread Even Rouault

Le samedi 07 juin 2014 21:36:21, Stefan Ziegler a écrit :
> Hi Even
> 
> Using python:
> 
> from osgeo import ogr
> 
> driver = ogr.GetDriverByName('WFS')
> wfs = driver.Open("WFS:http://www.catais.org/wfs/mopublic?";)
> 
> out = "/home/stefan/Projekte/GeoPackage/test5.gpkg"
> outDriver = ogr.GetDriverByName("GPKG")
> outDataSource = outDriver.CreateDataSource(out)
> 
> layer = wfs.GetLayerByName('hoheitsgrenzen__hoheitsgrenzpunkt')
> layer.SetAttributeFilter("bfsnr = 2601")
> outLayer = outDataSource.CopyLayer(layer,'test5')
> 
> I see 4 request in the apache log:
> 
> 1. GetCapabilities
> 2. DescribeFeatureType
> 3. GetFeature
> 4. GetFeature
> 
> (3) and (4) are equal except (3) adds
> ",xsd=/vsimem/tempwfs_0x1e50ad0/file.xsd". But no filter is added, pure
> GetFeature request.

Actually I was wrong. Cannot even remember my own code from 4 years ago ;-)
It does check that GetCapabilities reports LogicalOperators or 
Logical_Operators, which your server does not.
Strictly speaking your request doesn't require LogicalOperators, so that could 
be improved of course to be less restrictive...
But that must be an antiquitated implementation of WFS: only 1.0.0 and no 
logical operators... ?

> 
> regards
> Stefan
> 
> 
> 
> On Sat, Jun 7, 2014 at 8:56 PM, Even Rouault 
> 
> wrote:
> > Le samedi 07 juin 2014 20:46:51, Stefan Ziegler a écrit :
> > > Hi
> > > 
> > > I have a question regarding client/server sided filtering. According to
> > 
> > the
> > 
> > > wfs driver website [1] the driver is able to forward spatial and
> > 
> > attribute
> > 
> > > filter to the server. If this is not possible it will client-side only
> > > filtering. When does the driver "decide" wether it filters client or
> > 
> > server
> > 
> > > sided? I assume it reads the GetCapabilites file, right?
> > > 
> > > I do have a wfs server which understands ogc filtering (tested with
> > 
> > simple
> > 
> > > GET requests in browser)  but the ogr wfs driver does only client sided
> > > filtering. Probably a broken GetCapabilities file...
> > 
> > Stefan,
> > 
> > Well, it should maybe, but generally it assumes that the standard
> > operators (>,>=,<,<=,==,NOT,AND,OR) are implement by the server.
> > 
> > The choice between client-side and server-side filtering is based on the
> > content of the attribute filter. Some stuff can be turned into OGC Filter
> > language, some not (for example if using special OGR field names).
> > It maybe also due to a limitation of the current implementation that turn
> > the
> > SQL into OGC filter
> > 
> > What is your filter ?
> > 
> > > I'm using gdal/ogr 1.11.
> > > 
> > > [1]: http://www.gdal.org/drv_wfs.html
> > > 
> > > 
> > > best regards
> > > Stefan
> > 
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html

-- 
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] WFS driver and filtering

2014-06-07 Thread Stefan Ziegler

Hi Even

Using python:

from osgeo import ogr

driver = ogr.GetDriverByName('WFS')
wfs = driver.Open("WFS:http://www.catais.org/wfs/mopublic?";)

out = "/home/stefan/Projekte/GeoPackage/test5.gpkg"
outDriver = ogr.GetDriverByName("GPKG")
outDataSource = outDriver.CreateDataSource(out)

layer = wfs.GetLayerByName('hoheitsgrenzen__hoheitsgrenzpunkt')
layer.SetAttributeFilter("bfsnr = 2601")
outLayer = outDataSource.CopyLayer(layer,'test5')

I see 4 request in the apache log:

1. GetCapabilities
2. DescribeFeatureType
3. GetFeature
4. GetFeature

(3) and (4) are equal except (3) adds
",xsd=/vsimem/tempwfs_0x1e50ad0/file.xsd". But no filter is added, pure
GetFeature request.

regards
Stefan



On Sat, Jun 7, 2014 at 8:56 PM, Even Rouault 
wrote:

> Le samedi 07 juin 2014 20:46:51, Stefan Ziegler a écrit :
> > Hi
> >
> > I have a question regarding client/server sided filtering. According to
> the
> > wfs driver website [1] the driver is able to forward spatial and
> attribute
> > filter to the server. If this is not possible it will client-side only
> > filtering. When does the driver "decide" wether it filters client or
> server
> > sided? I assume it reads the GetCapabilites file, right?
> >
> > I do have a wfs server which understands ogc filtering (tested with
> simple
> > GET requests in browser)  but the ogr wfs driver does only client sided
> > filtering. Probably a broken GetCapabilities file...
>
> Stefan,
>
> Well, it should maybe, but generally it assumes that the standard operators
> (>,>=,<,<=,==,NOT,AND,OR) are implement by the server.
>
> The choice between client-side and server-side filtering is based on the
> content of the attribute filter. Some stuff can be turned into OGC Filter
> language, some not (for example if using special OGR field names).
> It maybe also due to a limitation of the current implementation that turn
> the
> SQL into OGC filter
>
> What is your filter ?
>
> >
> > I'm using gdal/ogr 1.11.
> >
> > [1]: http://www.gdal.org/drv_wfs.html
> >
> >
> > best regards
> > Stefan
>
> --
> 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] WFS driver and filtering

2014-06-07 Thread Even Rouault

Le samedi 07 juin 2014 20:46:51, Stefan Ziegler a écrit :
> Hi
> 
> I have a question regarding client/server sided filtering. According to the
> wfs driver website [1] the driver is able to forward spatial and attribute
> filter to the server. If this is not possible it will client-side only
> filtering. When does the driver "decide" wether it filters client or server
> sided? I assume it reads the GetCapabilites file, right?
> 
> I do have a wfs server which understands ogc filtering (tested with simple
> GET requests in browser)  but the ogr wfs driver does only client sided
> filtering. Probably a broken GetCapabilities file...

Stefan,

Well, it should maybe, but generally it assumes that the standard operators 
(>,>=,<,<=,==,NOT,AND,OR) are implement by the server.

The choice between client-side and server-side filtering is based on the 
content of the attribute filter. Some stuff can be turned into OGC Filter 
language, some not (for example if using special OGR field names).
It maybe also due to a limitation of the current implementation that turn the 
SQL into OGC filter

What is your filter ?

> 
> I'm using gdal/ogr 1.11.
> 
> [1]: http://www.gdal.org/drv_wfs.html
> 
> 
> best regards
> Stefan

-- 
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] WFS driver and filtering

2014-06-07 Thread Stefan Ziegler

Hi

I have a question regarding client/server sided filtering. According to the
wfs driver website [1] the driver is able to forward spatial and attribute
filter to the server. If this is not possible it will client-side only
filtering. When does the driver "decide" wether it filters client or server
sided? I assume it reads the GetCapabilites file, right?

I do have a wfs server which understands ogc filtering (tested with simple
GET requests in browser)  but the ogr wfs driver does only client sided
filtering. Probably a broken GetCapabilities file...

I'm using gdal/ogr 1.11.

[1]: http://www.gdal.org/drv_wfs.html


best regards
Stefan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-17 Thread Even Rouault

Selon xavier lhomme :

> Hi
>  I tried to add to the function SetAttributeFirlter the following  filter :
>  nam = 'MY#FIRST TEST ON'   but it doesn't work.
>  then I triedHttpUtility.UrlEncode( ) but it doesn't work too.
>
>  If I encode my string like this  nam = 'MY%23 FIRST+TEST+ON ' it works;
>
>  Could you explain a bit more what we need to encode ?

You shouldn't to have to do any encoding on the side of the user using the OGR
API (and if you do so, then the WFS driver might again URL-encode what you would
have already encoded... definitely not what you want). This must be done by the
WFS driver when composing the request to the WFS server. I've pushed a few fixes
to trunk 2 days ago to improve the URL encoding. Perhaps they will fix your
issue.

>
> xav
>


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-17 Thread xavier lhomme

Hi
 I tried to add to the function SetAttributeFirlter the following  filter :
 nam = 'MY#FIRST TEST ON'   but it doesn't work.
 then I triedHttpUtility.UrlEncode( ) but it doesn't work too.

 If I encode my string like this  nam = 'MY%23 FIRST+TEST+ON ' it works;

 Could you explain a bit more what we need to encode ?

xav
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-16 Thread Rahkonen Jukka

Even Rouault wrote:

> Note: yesterday after your emails, I've revised substantially how escaping
> was done in the WFS driver, because there were cases where URL-escaping
> would have been needed (for example if you passed '&' or '%'), so now for
> 'ä', you should see 25-43-33-25-41-34 (but that won't solve anything for
> Windows command line).
> There was also missing XML-escaping in some cases (yes, you need to XML-
> escape stuff, and then URL-escape it...).

I have heard that things are getting quite a bit harder to handle with WPS
when you may need to include the WFS request with its filters inside the
WPS request and escape everything correctly... Should things be escaped 
once, twice or not at all...

-Jukka-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-16 Thread Even Rouault

Selon Jukka Rahkonen :

> I think this is my last question about WFS and URL-encoding this time.
>
> I had a look how the WFS requests look in hexadecimals.
>
> My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä"
> inside
> ogc:Filter with http GET. First of those alternatives is an UTF-8 letter "ä"
> in
> URL-encoded format which looks as text like %C3%A4. Corresponding hex values
> in
> the GetFeature request seem to be 25-43-33-25-41-34. Another alternative that
> works also it to give letter "ä" in UTF-8 without URL-encoding it and then
> the
> hex values are C3-A4.
>
> My question is that are both alternatives correct to use in http GET?

This is a good question. My guess would be that there might be a old HTTP RFC
that only allowed ASCII characters and thus mandated URL-encoding, and perhaps a
newer RFC that accept all characters. Most servers seem to accept both.

> I have
> thought that URLs should use URL-encoding. OGR WFS driver is itself doing URL
> encoding for <,>," and [space]. Could it be so that expressing "ä" as plain
> C3-A4 in a filter works only because the http GET route is passing them on as
> raw, and WFS server by accident interprets them back to "ä" because it is
> internally using UTF-8?

Yes. But passing the character as 25-43-33-25-41-34 (URL-encoded) or C3-A4
(plain UTF8) requires the WFS driver to interpret it as UTF-8 in both cases. In
XML, UTF-8 is the default encoding, unless otherwise specified. But for other
parameters passed in the GET, this is indeed a good question to know how the
server is supposed which encoding it is...

Note: yesterday after your emails, I've revised substantially how escaping was
done in the WFS driver, because there were cases where URL-escaping would have
been needed (for example if you passed '&' or '%'), so now for 'ä', you should
see 25-43-33-25-41-34 (but that won't solve anything for Windows command line).
There was also missing XML-escaping in some cases (yes, you need to XML-escape
stuff, and then URL-escape it...).

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-16 Thread Jukka Rahkonen

I think this is my last question about WFS and URL-encoding this time.

I had a look how the WFS requests look in hexadecimals.

My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä" inside
ogc:Filter with http GET. First of those alternatives is an UTF-8 letter "ä" in
URL-encoded format which looks as text like %C3%A4. Corresponding hex values in
the GetFeature request seem to be 25-43-33-25-41-34. Another alternative that
works also it to give letter "ä" in UTF-8 without URL-encoding it and then the
hex values are C3-A4.

My question is that are both alternatives correct to use in http GET? I have
thought that URLs should use URL-encoding. OGR WFS driver is itself doing URL
encoding for <,>," and [space]. Could it be so that expressing "ä" as plain
C3-A4 in a filter works only because the http GET route is passing them on as
raw, and WFS server by accident interprets them back to "ä" because it is
internally using UTF-8?

There seem to be more to puzzle ordinary people like me. What looks like
character "ä" to me is also an extended ASCII character #228 and some
URL-encoders are translating it to %E4 (probably the reason for gvSIG WFS filter
error).
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
Some others are considering "ä" as a two-byte UTF-8 character and URL-encode 
that into %C3%A4 
http://www.w3schools.com/tags/ref_urlencode.asp

It must be funny to be a coder.

-Jukka-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-15 Thread Rahkonen Jukka

Even Rouault wrote:

> Looks a bit complicated. Actually, I'm thinking you could avoid those encoding
> problems with using :

> ogrinfo "WFS:http://188.64.1.61/cgi-bin/tinyows"; -sql --optfile sql.txt

> where sql.txt contains (with a UTF-8 text editor, such as Notepad++ correctly
> configured) :

> "select * from municipalities where kunta_ni1='Saarijärvi'"

> (The double-quote at the beginning and trailing of the file are necessary)

Yes, that works. It is a bit tricky but totally usable. I tried to save the 
whole command into Windows batch file as UTF-8 encoded but that does not work, 
it must be done exactly as you wrote. Hardest thing will be to learn other 
people to do it this way.

-Jukka-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-15 Thread Even Rouault

Le mercredi 15 août 2012 23:14:53, Rahkonen Jukka a écrit :
> Even Rouault wrote:
> 
> Le mercredi 15 août 2012 21:28:22, Jukka Rahkonen a écrit :
> >> GvSIG is also sending GetFeatures with http GET and filters and it had
> >> same kind of problems with special characters. Now the developers say
> >> that they have fixed URL encoding. I hope that the solution is somehow
> >> re-usable
> > 
> > I'm not sure this is a problem with URL encoding, but more a problem with
> > the fact that the Windows console is not using UTF-8. So even if the OGR
> > WFS driver did escape the special character, this wouldn't solve
> > anything, since it would get a non UTF8 character and would escape it
> > wrongly...
> > 
> > Some seraching would suggest that typing "chcp 65001" before might help,
> > but I'm not sure...
> > 
> > I'm wondering if the GDAL command line utilities shouldn't use special
> > instructions under Windows to better deal with Unicode characters. Some
> > search would suggest that using wmain() and/or SetConsoleOutputCP()
> > might help. Are there Windows programmers around that might give advice
> > on how to get arguments in UTF-8 from the Windows command line ?
> 
> > Anyway, with Linux, it works fine :
> 
> 
> If it happens to help, this is the only reliable method I have discovered
> so far for creating GetFeatures on Windows so that they work.
> 
> 1) Create a complete plain text request
> 2) Split it into two pieces and copy the part before XML filter to a safe
> place.
> http://188.64.1.61/cgi-bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFe
> ature&TYPENAME=lv:municipalities&FILTER= 3) Copy the filter part and drop
> into some URL encoding service like
> http://www.albionresearch.com/misc/urlencode.php.

Looks a bit complicated. Actually, I'm thinking you could avoid those encoding 
problems with using :

ogrinfo "WFS:http://188.64.1.61/cgi-bin/tinyows"; -sql --optfile sql.txt

where sql.txt contains (with a UTF-8 text editor, such as Notepad++ correctly 
configured) :

"select * from municipalities where kunta_ni1='Saarijärvi'"

(The double-quote at the beginning and trailing of the file are necessary)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-15 Thread Rahkonen Jukka

Even Rouault wrote:

Le mercredi 15 août 2012 21:28:22, Jukka Rahkonen a écrit :
>> GvSIG is also sending GetFeatures with http GET and filters and it had same
>> kind of problems with special characters. Now the developers say that they
>> have fixed URL encoding. I hope that the solution is somehow re-usable

> I'm not sure this is a problem with URL encoding, but more a problem with the
> fact that the Windows console is not using UTF-8. So even if the OGR WFS
> driver did escape the special character, this wouldn't solve anything, since
> it would get a non UTF8 character and would escape it wrongly...

> Some seraching would suggest that typing "chcp 65001" before might help, but
> I'm not sure...

> I'm wondering if the GDAL command line utilities shouldn't use special
> instructions under Windows to better deal with Unicode characters. Some search
> would suggest that using wmain() and/or SetConsoleOutputCP() might help. Are
> there Windows programmers around that might give advice on how to get
> arguments in UTF-8 from the Windows command line ?

> Anyway, with Linux, it works fine :

If it happens to help, this is the only reliable method I have discovered so 
far for 
creating GetFeatures on Windows so that they work.

1) Create a complete plain text request 
2) Split it into two pieces and copy the part before XML filter to a safe place.
http://188.64.1.61/cgi-bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=
3) Copy the filter part and drop into some URL encoding service like 
http://www.albionresearch.com/misc/urlencode.php. 

For example this goes to the URL-encoding service
http://www.opengis.net/ogc"; xmlns:lv="http://latuviitta.fi/"; 
xmlns:gml="http://www.opengis.net/gml";>kunta_ni1Saarijärvi

and this comes back
%3CFilter%20xmlns%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%20xmlns%3Alv%3D%22http%3A%2F%2Flatuviitta.fi%2F%22%20xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ekunta_ni1%3C%2FPropertyName%3E%3CLiteral%3ESaarij%C3%A4rvi%3C%2FLiteral%3E%3C%2FPropertyIsEqualTo%3E%3C%2FFilter%3E

4) Combine the starting part of GetFeature from step 2) and URL-encoded filter 
from step 3)
This new GetFeature can be sent with a browser or with wget or curl.

You can guess that I do not really use this method for any real work.  Instead 
I am either using Kosmo
GIS as WFS client because it is using http POST (and has a query builder), or 
then I send requests 
from browser with POST method by using Poster add-on.  However, using WFS 
through OGR offers 
so nice possibilities that it would be great to learn some way for making also 
attribute filters with special characters to work - on Windows and in Finland.

-Jukka-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-15 Thread Even Rouault

Le mercredi 15 août 2012 21:28:22, Jukka Rahkonen a écrit :
> GvSIG is also sending GetFeatures with http GET and filters and it had same
> kind of problems with special characters. Now the developers say that they
> have fixed URL encoding. I hope that the solution is somehow re-usable

I'm not sure this is a problem with URL encoding, but more a problem with the 
fact that the Windows console is not using UTF-8. So even if the OGR WFS 
driver did escape the special character, this wouldn't solve anything, since 
it would get a non UTF8 character and would escape it wrongly...

Some seraching would suggest that typing "chcp 65001" before might help, but 
I'm not sure...

I'm wondering if the GDAL command line utilities shouldn't use special 
instructions under Windows to better deal with Unicode characters. Some search 
would suggest that using wmain() and/or SetConsoleOutputCP() might help. Are 
there Windows programmers around that might give advice on how to get 
arguments in UTF-8 from the Windows command line ?

Anyway, with Linux, it works fine :

$ ogrinfo "WFS:http://188.64.1.61/cgi-bin/tinyows"; -sql "select * from 
municipalities where kunta_ni1='Saarijärvi'" ro --debug on
WFS: http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=1.1.0,1.0.0
HTTP: Fetch(http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=1.1.0,1.0.0)
WFS: GetFeature operation supports hits
WFS: Transaction support !
OGR: OGROpen(WFS:http://188.64.1.61/cgi-bin/tinyows/0x1eaf190) succeeded as 
WFS.
INFO: Open of `WFS:http://188.64.1.61/cgi-bin/tinyows'
  using driver `WFS' successful.
layer names ignored in combination with -sql.
HTTP: Fetch(http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=lv:municipalities,lv:mml_kunta10k_2011_l,lv:mml_kunta10k_2011_p,lv:mml_kunta100k_2011_l,lv:mml_kunta100k_2011_p,lv:mml_kunta250k_2011_l,lv:mml_kunta250k_2011_p,lv:mml_kunta1000k_2011_l,lv:mml_kunta1000k_2011_p,lv:mml_kunta4500k_2011_l,lv:mml_kunta4500k_2011_p,lv:mml_airport,lv:mml_asemat,lv:mml_avi1_l,lv:mml_avi1_p,lv:mml_cityp,lv:mml_coast_l,lv:mml_coast_p,lv:mml_dcont_l,lv:mml_dcont_p,lv:mml_forest,lv:mml_hcont_l,lv:mml_hcont_p,lv:mml_hpoint,lv:mml_kunta1_l,lv:mml_kunta1_p,lv:mml_kunta1_maa_alue,lv:mml_lake_l,lv:mml_lake_p,lv:mml_maaku1_l,lv:mml_maaku1_p,lv:mml_namep,lv:mml_pelto,lv:mml_railway,lv:mml_river,lv:mml_rivera_l,lv:mml_rivera_p,lv:mml_road,lv:mml_suot,lv:mml_taajama,lv:mml_paikannimet20,lv:peltolohkot_2011,lv:pks_pienalue,lv:pks_suuralue,lv:pks_tilastoalue,lv:pks_asuinalueet,lv:pks_teollisuusalueet,lv:pks_viheralueet,lv:pks_maankaytto,lv:pks_jarvet)

Layer name: municipalities
Geometry: Multi Polygon
WFS: http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=http://www.opengis.net/ogc"; xmlns:lv="http://latuviitta.fi/"; 
xmlns:gml="http://www.opengis.net/gml";>kunta_ni1Saarijärvi&RESULTTYPE=hits
HTTP: Fetch(http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%20xmlns:lv=%22http://latuviitta.fi/%22%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ekunta_ni1%3C/PropertyName%3E%3CLiteral%3ESaarijärvi%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E&RESULTTYPE=hits)
Feature Count: 1
WFS: http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=http://www.opengis.net/ogc"; xmlns:lv="http://latuviitta.fi/"; 
xmlns:gml="http://www.opengis.net/gml";>kunta_ni1Saarijärvi
VSICURL: Start download for http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%20xmlns:lv=%22http://latuviitta.fi/%22%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ekunta_ni1%3C/PropertyName%3E%3CLiteral%3ESaarijärvi%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E
GML: Using Expat reader
GML: Global SRS = EPSG:3067
GML: Using /vsimem/tempwfs_0x1f38d60/file.xsd
GML: ResetReading()
GML: ResetReading()
GML: ResetReading()
Extent: (372349.75, 6933225.50) - (433496.625000, 6976330.00)
Layer SRS WKT:
PROJCS["ETRS89 / TM35FIN(E,N)",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AXIS["Latitude",NORTH],
AXIS["Longitude",EAST],
AUTHORITY["EPSG","4258"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_me

Re: [gdal-dev] WFS driver does not do URL-encoding right

2012-08-15 Thread Jukka Rahkonen

Jukka Rahkonen  mmmtike.fi> writes:

> 
> Hi,
> 
> It looks like it is not possible to use some special characters in filters 
> with
> OGR WFS driver.

GvSIG is also sending GetFeatures with http GET and filters and it had same kind
of problems with special characters. Now the developers say that they have fixed
URL encoding. I hope that the solution is somehow re-usable
https://devel.gvsig.org/redmine/issues/984

-Jukka-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WFS driver does not do URL-encoding right

2012-08-08 Thread Jukka Rahkonen

Hi,

It looks like it is not possible to use some special characters in filters with
OGR WFS driver.

This command works fine:
http://188.64.1.61/cgi-bin/tinyows -sql "select * from municipalities where
kunta_ni1='Helsinki'"

However, the WFS request fails if I use fore example 'Saarijärvi' as an
attribute value. The reason is that character 'ä' does not get URL-encoded into
%C3%A4 as it should in the GetFeature request. This is the request that is sent
to WFS server. 

http://188.64.1.61/cgi-bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=lv:municipalities&FILTER=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%20xmlns:lv=%22http://latuviitta.fi/%22%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ekunta_ni1%3C/PropertyName%3E%3CLiteral%3ESaarij�rvi%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E

Placing %C3%A4 into where it belongs makes the request to work.
I am on Windows XP with Finnish default settings.

Is this something worth filing a ticket or what?

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [WFS Driver] Http Error Code 414

2012-06-19 Thread Even Rouault

Le mardi 19 juin 2012 21:41:06, xavier lhomme a écrit :
> From specification
> 
> When using the HTTP POST method, the content type for XML encoded WFS
> requests must be set to text/xml.  When using the HTTP POST method, the
> content type for KVP encoded WFS requests must be set to
> application/x-www-form-urlencoded and the content of the document must be
> equivalent to the query string of an HTTP GET request.  That is, the
> content must be equivalent to the string that follows the ‘?’ character in
> a URL encoded GET request.  Of course, the content must be encoded [10] to
> protect special characters.
> 
> Then I will try to split the url after ? Encode the end of the url to
> protect special character, set application/x-www-form-urlencoded and the
> end url to the post parameter

In fact, the spec describe 2 different methods (the above formatting of the 
text of the specification is a bit confusing. Interested readers should 
directly look at the spec and the table in it).

I didn't remember that KVP could also be used in POST. I thought of the XML 
form, like  :


http://www.someserver.com/myns";
xmlns:wfs="http://www.opengis.net/wfs";
xmlns:ogc="http://www.opengis.net/ogc";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.1.0/WFS.xsd">





The best is to try of course what works with your server.

> 
> And if not working i will try the xml form...
> Le 19 juin 2012 19:40, "Even Rouault"  a
> 
> écrit :
> > Le mardi 19 juin 2012 17:06:17, xavier lhomme a écrit :
> > > Hi
> > > I tried to submit a POST request with the KVP form to an ArcGIS Server
> > 
> > 10.0
> > 
> > > but in response I've got an XML Parsing error.
> > > 
> > >  Do I need to translate the KVP form of the url into an XML form ?
> > 
> > Yes, the content you send in a POST is different from the KVP of a GET.
> > There
> > are examples (if I remember correctly) in the OGC WFS spec.
> > 
> > > xav
> > > 
> > > 
> > > 2012/6/12 Even Rouault 
> > > 
> > > > Le mardi 12 juin 2012 14:38:05, xavier lhomme a écrit :
> > > > > Hello
> > > > > 
> > > > >  I'm requesting a WFS source with a very long request. The URI
> > > > >  generated
> > > > 
> > > > by
> > > > 
> > > > > the WFS driver is very long (more than 2048). In return I' ve got
> > > > > an HTTP error code 414.
> > > > > 
> > > > >  OGRWFSDataSource::HTTPFetch function should be protected against
> > 
> > very
> > 
> > > > long
> > > > 
> > > > > URI and switch between a GET request to a POST request.
> > > > 
> > > > Patch welcome and public server for testing :-)
> > > > 
> > > > > best regards
> > > > > xavier
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [WFS Driver] Http Error Code 414

2012-06-19 Thread xavier lhomme

>From specification

When using the HTTP POST method, the content type for XML encoded WFS
requests must be set to text/xml.  When using the HTTP POST method, the
content type for KVP encoded WFS requests must be set to
application/x-www-form-urlencoded and the content of the document must be
equivalent to the query string of an HTTP GET request.  That is, the
content must be equivalent to the string that follows the ‘?’ character in
a URL encoded GET request.  Of course, the content must be encoded [10] to
protect special characters.

Then I will try to split the url after ? Encode the end of the url to
protect special character, set application/x-www-form-urlencoded and the
end url to the post parameter

And if not working i will try the xml form...
Le 19 juin 2012 19:40, "Even Rouault"  a
écrit :

> Le mardi 19 juin 2012 17:06:17, xavier lhomme a écrit :
> > Hi
> > I tried to submit a POST request with the KVP form to an ArcGIS Server
> 10.0
> > but in response I've got an XML Parsing error.
> >
> >  Do I need to translate the KVP form of the url into an XML form ?
>
> Yes, the content you send in a POST is different from the KVP of a GET.
> There
> are examples (if I remember correctly) in the OGC WFS spec.
>
> >
> > xav
> >
> >
> > 2012/6/12 Even Rouault 
> >
> > > Le mardi 12 juin 2012 14:38:05, xavier lhomme a écrit :
> > > > Hello
> > > >
> > > >  I'm requesting a WFS source with a very long request. The URI
> > > >  generated
> > >
> > > by
> > >
> > > > the WFS driver is very long (more than 2048). In return I' ve got an
> > > > HTTP error code 414.
> > > >
> > > >  OGRWFSDataSource::HTTPFetch function should be protected against
> very
> > >
> > > long
> > >
> > > > URI and switch between a GET request to a POST request.
> > >
> > > Patch welcome and public server for testing :-)
> > >
> > > > best regards
> > > > xavier
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [WFS Driver] Http Error Code 414

2012-06-19 Thread Even Rouault

Le mardi 19 juin 2012 17:06:17, xavier lhomme a écrit :
> Hi
> I tried to submit a POST request with the KVP form to an ArcGIS Server 10.0
> but in response I've got an XML Parsing error.
> 
>  Do I need to translate the KVP form of the url into an XML form ?

Yes, the content you send in a POST is different from the KVP of a GET. There 
are examples (if I remember correctly) in the OGC WFS spec.

> 
> xav
> 
> 
> 2012/6/12 Even Rouault 
> 
> > Le mardi 12 juin 2012 14:38:05, xavier lhomme a écrit :
> > > Hello
> > > 
> > >  I'm requesting a WFS source with a very long request. The URI
> > >  generated
> > 
> > by
> > 
> > > the WFS driver is very long (more than 2048). In return I' ve got an
> > > HTTP error code 414.
> > > 
> > >  OGRWFSDataSource::HTTPFetch function should be protected against very
> > 
> > long
> > 
> > > URI and switch between a GET request to a POST request.
> > 
> > Patch welcome and public server for testing :-)
> > 
> > > best regards
> > > xavier
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [WFS Driver] Http Error Code 414

2012-06-19 Thread xavier lhomme

Hi
I tried to submit a POST request with the KVP form to an ArcGIS Server 10.0
but in response I've got an XML Parsing error.

 Do I need to translate the KVP form of the url into an XML form ?

xav


2012/6/12 Even Rouault 

> Le mardi 12 juin 2012 14:38:05, xavier lhomme a écrit :
> > Hello
> >
> >  I'm requesting a WFS source with a very long request. The URI generated
> by
> > the WFS driver is very long (more than 2048). In return I' ve got an HTTP
> > error code 414.
> >  OGRWFSDataSource::HTTPFetch function should be protected against very
> long
> > URI and switch between a GET request to a POST request.
>
> Patch welcome and public server for testing :-)
>
> >
> > best regards
> > xavier
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [WFS Driver] Http Error Code 414

2012-06-12 Thread Even Rouault

Le mardi 12 juin 2012 14:38:05, xavier lhomme a écrit :
> Hello
> 
>  I'm requesting a WFS source with a very long request. The URI generated by
> the WFS driver is very long (more than 2048). In return I' ve got an HTTP
> error code 414.
>  OGRWFSDataSource::HTTPFetch function should be protected against very long
> URI and switch between a GET request to a POST request.

Patch welcome and public server for testing :-)

> 
> best regards
> xavier
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] [WFS Driver] Http Error Code 414

2012-06-12 Thread xavier lhomme

Hello

 I'm requesting a WFS source with a very long request. The URI generated by
the WFS driver is very long (more than 2048). In return I' ve got an HTTP
error code 414.
 OGRWFSDataSource::HTTPFetch function should be protected against very long
URI and switch between a GET request to a POST request.

best regards
xavier
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver, ogrinfo and GetFeature

2011-12-19 Thread Even Rouault

Selon Jukka Rahkonen :

> Hi,
>
> If user wants to read a summary of a certain WFS feature type with a command
> like
>
> ogrinfo -ro -so WFS:http://server.com/wfs ns:typeName
>
> GDAL seems to send then four separate commands:
>
> First:
> SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=1.1.0,1.0.0
> Second:
> SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=[list of all
> the
> typenames in the whole service]
> Third:
>
SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName&RESULTTYPE=hits
> Fourth:
> SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName
>
> Questions:
> - Why to send DescribeFeatureType for all the feature types when user is only
> interested in the named one "ns:typeName"?

This an optimization for the case where you want to read several layers. I've
observed that the cost of a DescribeFeatureType request with N feature types is
generally significantly cheaper than the cost of N request with one feature
type. Of course, there are situations like the above where you don't win. But
you cannot always win, right ? (and the WFS driver cannot know that ogrinfo will
only request one layer)

> - Is is necessary to send the fourth request and read the whole layer from
> the
> service? I guess it is because GDAL wants to see the real geometries so it
> can
> calculate correct extents for the layer but it can be quite a heavy load for
> the
> WFS server.

Correct, this is necessary to get the extent.

>
> In fact the following line leads to an ultimate query "get everything that
> exists in the WFS service"
>
> orginfo -al -so WFS:http://server.com/wfs
>
> This will make one by one full GetFeatures for all the feature types in the
> whole service. My service has 55 feature types and many of them has more than
> million features and ogrinfo will probably fail if my server won't fail
> earlier
> with sending a few gigabytes of GML. I consider it a little bit dangerous
> that
> users can send such requests accidentally. I think that at least users should
> especially do something before GDAL would create the fourth request, the
> plain
> GetFeature.

Not much can be done : there's no way to make interact the user with the driver
and ogrinfo doesn't know which requests are expensive or not. Perhaps one could
have a cheaper implementation of GetExtent() based on what is in the
GetCapabilities response. But AFAIR, you only get the bounding box in
latitude/longitude, even if the default SRS is something else. One could try to
reproject the lat/long bounding box into the target SRS, but that might be
inaccurate in some cases, not to say plainly wrong (consider UTM zone 60, polar
projections, etc...). Even in the case where the SRS is EPSG:4326, I've avoided
to use the advertized bounding box because of uncertainty about what the
coordinate order should be, and how WFS servers have understood or misunderstood
the spec (see ticket http://trac.osgeo.org/gdal/ticket/4041 for more details).

In the meantime, you could just comment the line in ogrinfo that calls
GetExtent().

>
> -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] WFS driver, ogrinfo and GetFeature

2011-12-19 Thread Jukka Rahkonen

Hi,

If user wants to read a summary of a certain WFS feature type with a command 
like

ogrinfo -ro -so WFS:http://server.com/wfs ns:typeName 

GDAL seems to send then four separate commands:

First:
SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=1.1.0,1.0.0
Second:
SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=[list of all the
typenames in the whole service]
Third:
SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName&RESULTTYPE=hits
Fourth:
SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName

Questions:
- Why to send DescribeFeatureType for all the feature types when user is only
interested in the named one "ns:typeName"? 
- Is is necessary to send the fourth request and read the whole layer from the
service? I guess it is because GDAL wants to see the real geometries so it can
calculate correct extents for the layer but it can be quite a heavy load for the
WFS server.

In fact the following line leads to an ultimate query "get everything that
exists in the WFS service"

orginfo -al -so WFS:http://server.com/wfs

This will make one by one full GetFeatures for all the feature types in the
whole service. My service has 55 feature types and many of them has more than
million features and ogrinfo will probably fail if my server won't fail earlier
with sending a few gigabytes of GML. I consider it a little bit dangerous that
users can send such requests accidentally. I think that at least users should
especially do something before GDAL would create the fourth request, the plain
GetFeature.

-Jukka Rahkonen-


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

38 matches

Mail list logo