[Geoserver-users] Problem reprojecting from EPSG:4326

I’m trying to reproject a layer with native srs EPSG:4326 to declared srs EPSG:3375. The native layer is from a PostGIS store.

When I view using QGIS 1.7-dev via wfs, the geometries are still in their native coordinates. Curiously, the computed Lat/Lon Bounding Box appear to be a single point (see attached screen cap).

I have tried with a few other layers and I get the same result when reprojecting from 4326 to another srs.

Any ideas?

Thanks

Hilmy

GeoServerReprojectNative2Declared.png

Forgot to say I was using Geoserver 2.0.2 on Ubuntu 10.04 Server.

I just tried on the latest 2.1-RC5 on Windows 7 (using the installer) and it works
fine. The lat/lon bounding box values have no effect.

Regards

Hilmy

On Tue, Apr 26, 2011 at 5:31 PM, Hilmy Hashim <hilmyh@anonymised.com…> wrote:

I’m trying to reproject a layer with native srs EPSG:4326 to declared srs EPSG:3375. The native layer is from a PostGIS store.

When I view using QGIS 1.7-dev via wfs, the geometries are still in their native coordinates. Curiously, the computed Lat/Lon Bounding Box appear to be a single point (see attached screen cap).

I have tried with a few other layers and I get the same result when reprojecting from 4326 to another srs.

Any ideas?

Thanks

Hilmy

On 26 April 2011 05:31, Hilmy Hashim <hilmyh@anonymised.com> wrote:

I'm trying to reproject a layer with native srs EPSG:4326 to declared srs
EPSG:3375. The native layer is from a PostGIS store.
When I view using QGIS 1.7-dev via wfs, the geometries are still in their
native coordinates. Curiously, the computed Lat/Lon Bounding Box appear to
be a single point (see attached screen cap).
I have tried with a few other layers and I get the same result when
reprojecting from 4326 to another srs.

That's not how that works - you just put the projection of the data in
those boxes. If the correct SRS is being found in default then leave
declared blank. Then specify which projection you'd like your map to
be in (3375?) in the map request you send using SRS=EPSG:3375

Ian
--
Ian Turton

On 26 April 2011 14:33, Hilmy Hashim <hilmyh@anonymised.com> wrote:

Thanks Ian, I see what you mean and it appears to work.
But isn't the SRS Handling option "Reproject Native to Declared" meant for
changing the srs of your native data?

Only when your data is lying about it's projection.

Ian
--
Ian Turton

Hi,

Ian does not perhaps use very much WFS. With WFS and especially with version 1.0.0 there is a real need to use the native and declared SRSs and Reproject Native to Declared like Hilmy did. The declared SRS comes as the default SRS for WFS data and because WFS 1.0.0 standard does not support reprojection it is the only standard way to reproject data. Geoserver does support the use of srsName with WFS 1.0.0 but it an extra vendor option.

-Jukka Rahkonen-

Ian Turton wrote:

On 26 April 2011 14:33, Hilmy Hashim <hilmyh@anonymised.com> wrote:

Thanks Ian, I see what you mean and it appears to work.
But isn't the SRS Handling option "Reproject Native to Declared" meant for
changing the srs of your native data?

Only when your data is lying about it's projection.

Ian

--

Ian Turton

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Apr 26, 2011 at 8:38 PM, Ian Turton <ijturton@anonymised.com> wrote:

On 26 April 2011 14:33, Hilmy Hashim <hilmyh@anonymised.com> wrote:

Thanks Ian, I see what you mean and it appears to work.
But isn't the SRS Handling option "Reproject Native to Declared" meant for
changing the srs of your native data?

Only when your data is lying about it's projection.

It's more complicated that that.

There are three options:
- leave native: to be used when you want to lie to your user, but want
to actually keep on using the math of the original projection. Rarely
ever needed
- force declared: to be used when the native projection is missing or
wrong, will make the native be completely ignored. Works fine as a
default too (that is, when native and declared are the same)
- reproject from native: this actually has two valid usages.
  The first one, for which this was born, is when you have a legit
native SRS that cannot be matched to any official EPSG code. It's
probably some custom projection or some obscure/old national
projection.
  By using "reproject to declared" you can choose a valid EPSG code to
be advertised, and publish your data as if it was in that projection.
  The other legit case is then one mentioned by Jukka, you have
standard WFS 1.0 clients that cannot use the srsName parameter (which,
in WFS 1.0, is to be considered a GeoServer vendor extension) but you
still want to provide them a layer in one or more projections (WFS 1.0
wise). You can do that by publishing the same layer multiple times
doing the "reproject from native" dance, changing each time the
declared srs.

Makes sense?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Thanks Andrea for the explanation. My original thinking was more in line with your last case. I’m dealing with 3 different projections - cadaster, topo and data collected using gps. I need to mix and match them.

But my problem was that 4326 as native will not reproject to a different declared projection in geoserevr 2.0.2 on Ubuntu 10.04.

Regards

Hilmy

On Wed, Apr 27, 2011 at 3:51 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Apr 26, 2011 at 8:38 PM, Ian Turton <ijturton@anonymised.com> wrote:

On 26 April 2011 14:33, Hilmy Hashim <hilmyh@anonymised.com> wrote:

Thanks Ian, I see what you mean and it appears to work.
But isn’t the SRS Handling option “Reproject Native to Declared” meant for
changing the srs of your native data?

Only when your data is lying about it’s projection.

It’s more complicated that that.

There are three options:

  • leave native: to be used when you want to lie to your user, but want
    to actually keep on using the math of the original projection. Rarely
    ever needed
  • force declared: to be used when the native projection is missing or
    wrong, will make the native be completely ignored. Works fine as a
    default too (that is, when native and declared are the same)
  • reproject from native: this actually has two valid usages.
    The first one, for which this was born, is when you have a legit
    native SRS that cannot be matched to any official EPSG code. It’s
    probably some custom projection or some obscure/old national
    projection.
    By using “reproject to declared” you can choose a valid EPSG code to
    be advertised, and publish your data as if it was in that projection.
    The other legit case is then one mentioned by Jukka, you have
    standard WFS 1.0 clients that cannot use the srsName parameter (which,
    in WFS 1.0, is to be considered a GeoServer vendor extension) but you
    still want to provide them a layer in one or more projections (WFS 1.0
    wise). You can do that by publishing the same layer multiple times
    doing the “reproject from native” dance, changing each time the
    declared srs.

Makes sense?

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Hi,

The client may also do something odd. Have a tried what happens if you send the requests from a browser instead of using QGis? Something like

http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=getCapabilities
http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=describeFeatureType
http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=getFeature&typeName=your_type_name&maxFeatures=10

Have a try also by adding some srsName and with version 1.0.0.

-Jukka Rahkonen-

-----Alkuperäinen viesti-----
Lähettäjä: Hilmy Hashim [mailto:hilmyh@anonymised.com]
Lähetetty: ti 26.4.2011 23:04
Vastaanottaja: Andrea Aime
Kopio: Ian Turton; geoserver-users
Aihe: Re: [Geoserver-users] Problem reprojecting from EPSG:4326

Thanks Andrea for the explanation. My original thinking was more in line
with your last case. I'm dealing with 3 different projections - cadaster,
topo and data collected using gps. I need to mix and match them.

But my problem was that 4326 as native will not reproject to a different
declared projection in geoserevr 2.0.2 on Ubuntu 10.04.

Regards

*Hilmy*

On Wed, Apr 27, 2011 at 3:51 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Tue, Apr 26, 2011 at 8:38 PM, Ian Turton <ijturton@anonymised.com> wrote:
> On 26 April 2011 14:33, Hilmy Hashim <hilmyh@anonymised.com> wrote:
>> Thanks Ian, I see what you mean and it appears to work.
>> But isn't the SRS Handling option "Reproject Native to Declared" meant
for
>> changing the srs of your native data?
>
> Only when your data is lying about it's projection.

It's more complicated that that.

There are three options:
- leave native: to be used when you want to lie to your user, but want
to actually keep on using the math of the original projection. Rarely
ever needed
- force declared: to be used when the native projection is missing or
wrong, will make the native be completely ignored. Works fine as a
default too (that is, when native and declared are the same)
- reproject from native: this actually has two valid usages.
The first one, for which this was born, is when you have a legit
native SRS that cannot be matched to any official EPSG code. It's
probably some custom projection or some obscure/old national
projection.
By using "reproject to declared" you can choose a valid EPSG code to
be advertised, and publish your data as if it was in that projection.
The other legit case is then one mentioned by Jukka, you have
standard WFS 1.0 clients that cannot use the srsName parameter (which,
in WFS 1.0, is to be considered a GeoServer vendor extension) but you
still want to provide them a layer in one or more projections (WFS 1.0
wise). You can do that by publishing the same layer multiple times
doing the "reproject from native" dance, changing each time the
declared srs.

Makes sense?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Forgot to send to list.

Hilmy

---------- Forwarded message ----------
From: Hilmy Hashim <hilmyh@anonymised.com>
Date: Wed, Apr 27, 2011 at 3:25 PM
Subject: Re: [Geoserver-users] Problem reprojecting from EPSG:4326
To: Rahkonen Jukka <Jukka.Rahkonen@anonymised.com>

OK, I did the tests suggested by Rahkonen and here are the results using the browser (Chrome) only:

wfs getCapabilities OK
wfs describeFeatureType OK

wfs getFeature - I did tests using postgis table on geoserver 2.0.2 (tests 1,2,3) and the source shapefile on geoserver 2.0.2 (tests 4,5,6) and 2.1-Beta3 (tests 7,8,9) Both geoservers on Ubuntu 10.04 on different machines.

Tests 1, 4 and 7 are the gml returns for Force Declared EPSG:4326 for all 3 scenarios.

With all 3 scenarios, appending srsName=EPSG:3375 to the getFeature wfs request gives the correct result on the Force Declared EPSG:4326 layer (see tests 2, 5 and 8).

On Geoserver 2.0.2, doing a Reproject Native to Declared EPSG:3375 (tests 3 and 6) returns the unprojected lat/lon coordinates. Note however, the lat/lon has been transposed to "easting/northing’ order. Also, the gml is returned as a MultiSurface rather than a MultiPolygon. On Geoserever 2.1-Beta3, the returned gml (test 9) is correct.

Here are the excerpts from the GML:---------------------------------------------------------------------------------------------------

1. Geoserver 2.0.2 PostGIS store Force Declared= EPSG:4326
staging:the_geom
<gml:MultiPolygon srsName=“urn:x-ogc:def:crs:EPSG:4326”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
4.542599344415663 100.9240152415304 4.542713251149678 100.92357256684761 4.542834977410518 100.92360568672036 4.542717204630615 100.92404258680193 4.542599344415663 100.9240152415304
</gml:posList>

2. Geoserver 2.0.2 PostGIS store Force Declared= EPSG:4326 srsName=EPSG:3375
staging:the_geom
<gml:MultiPolygon srsName=“http://www.opengis.net/gml/srs/epsg.xml#3375”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
325812.9316482484 502845.62774417095 325763.8576383463 502858.40349085734 325767.58227272885 502871.84945757256 325816.0139344604 502858.6485958141 325812.9316482484 502845.62774417095
</gml:posList>

3. Geoserver 2.0.2 PostGIS store Reproject Native to Declared= EPSG:3375
staging:the_geom
<gml:MultiSurface srsName=“urn:x-ogc:def:crs:EPSG:3375”>
gml:surfaceMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
100.9240152415304 4.542599344415663 100.92357256684761 4.542713251149678 100.92360568672036 4.542834977410518 100.92404258680193 4.542717204630615 100.9240152415304 4.542599344415663

4. Geoserver 2.0.2 Shapefile store Force Declared= EPSG:4326
test:the_geom
<gml:MultiPolygon srsName=“urn:x-ogc:def:crs:EPSG:4326”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
4.542599344415663 100.9240152415304 4.542713251149678 100.92357256684761 4.542834977410518 100.92360568672036 4.542717204630615 100.92404258680193 4.542599344415663 100.9240152415304
</gml:posList>

5. Geoserver 2.0.2 Shapefile store Force Declared= EPSG:4326 srsName=EPSG:3375
test:the_geom
<gml:MultiPolygon srsName=“http://www.opengis.net/gml/srs/epsg.xml#3375”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
325812.9316482484 502845.62774417095 325763.8576383463 502858.40349085734 325767.58227272885 502871.84945757256 325816.0139344604 502858.6485958141 325812.9316482484 502845.62774417095
</gml:posList>

6. Geoserver 2.0.2 Shapefile store Reproject Native to Declared= EPSG:3375
test:the_geom
<gml:MultiSurface srsName=“urn:x-ogc:def:crs:EPSG:3375”>
gml:surfaceMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
100.9240152415304 4.542599344415663 100.92357256684761 4.542713251149678 100.92360568672036 4.542834977410518 100.92404258680193 4.542717204630615 100.9240152415304 4.542599344415663
</gml:posList>

7. Geoserver 2.1-Beta3 Shapefile store Force Declared= EPSG:4326
test:the_geom
<gml:MultiPolygon srsDimension=“2” srsName=“urn:x-ogc:def:crs:EPSG:4326”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
4.542599344415663 100.9240152415304 4.542713251149678 100.92357256684761 4.542834977410518 100.92360568672036 4.542717204630615 100.92404258680193 4.542599344415663 100.9240152415304
</gml:posList>

8. Geoserver 2.1-Beta3 Shapefile store Force Declared= EPSG:4326 srsName=EPSG:3375
test:the_geom
<gml:MultiPolygon srsDimension=“2” srsName=“http://www.opengis.net/gml/srs/epsg.xml#3375”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
325812.9316482484 502845.62774417095 325763.8576383463 502858.40349085734 325767.58227272885 502871.84945757256 325816.0139344604 502858.6485958141 325812.9316482484 502845.62774417095
</gml:posList>

9. Geoserver 2.1-Beta3 Shapefile store Reproject Native to Declared= EPSG:3375
test:the_geom
<gml:MultiPolygon srsDimension=“2” srsName=“urn:x-ogc:def:crs:EPSG:3375”>
gml:polygonMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList
325812.9316482489 502845.6277441713 325763.85763834673 502858.40349085775 325767.58227272937 502871.8494575729 325816.01393446093 502858.64859581465 325812.9316482489 502845.6277441713
</gml:posList>

Hilmy

On Wed, Apr 27, 2011 at 5:55 AM, Rahkonen Jukka <Jukka.Rahkonen@anonymised.com> wrote:

Hi,

The client may also do something odd. Have a tried what happens if you send the requests from a browser instead of using QGis? Something like

http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=getCapabilities
http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=describeFeatureType
http://localhost:8080/geoserver/wfs?service=wfs&version=1.1.0&request=getFeature&typeName=your_type_name&maxFeatures=10

Have a try also by adding some srsName and with version 1.0.0.

-Jukka Rahkonen-