Hi Jukka,

The problem wasn't with the WMS in the end. I had the coordinates in our
database (forming a layer on top of the cascaded WMS) in the EPSG dictated
order: (lat, lon) so the points on my map were rotated 180 degrees and
mirrored across (0,0). I just had to redefine all of the Point geometries
in the database to be (lon, lat).


On Wed, Aug 2, 2017 at 6:51 AM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
> You wrote:
>
> "I'm using a cascading WMS (from another Geoserver) to put a map behind
> our GPS station locations and I had to switch all the coordinates to make
> the projections overlay correctly."
>
>
> Could you explain why do you think that WKT definition is the reason for
> your trouble with cascading WMS and what coordinates you need to switch?
> Cascading WMS is usually painless if user remembers that for WMS versions
> prior 1.3 the BBOX is expressed always in longitude-latitude /
> easting-northing order for all the projections.  In WMS 1.3 the official
> axis order is to be honoured. Could it be that you are cascading WMS 1.1.x
> and you make a wrong assumption that BBOX should be in lat-lon order? If
> that is the case, simply start cascading WMS 1.3.0.
>
>
> -Jukka Rahkonen-
>
>
>
>
> ------------------------------
> *Lähettäjä:* Gavin Medley <med...@unavco.org>
> *Lähetetty:* 1. elokuuta 2017 20:15
> *Vastaanottaja:* geoserver-users@lists.sourceforge.net
> *Aihe:* [Geoserver-users] EPSG:4326 Incorrect WKT - Coordinates Reversed!
>
> Hi all,
>
> I believe that the WKT for EPGS:4326 in Geoserver is incorrect. Can
> someone verify?
>
> Note the lat lon coordinate order in the following strings. Geoserver
> displays:
>
> GEOGCS["WGS 84",
> DATUM["World Geodetic System 1984",
> SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
> UNIT["degree", 0.017453292519943295],
> AXIS["Geodetic longitude", EAST],
> AXIS["Geodetic latitude", NORTH],
> AUTHORITY["EPSG","4326"]]
>
> However, epsg-registry.org lists the official WKT as:
>
> GEODCRS["WGS 84",
>   DATUM["World Geodetic System 1984",
>     ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]],
>   CS[ellipsoidal,2],
>     AXIS["latitude",north,ORDER[1]],
>     AXIS["longitude",east,ORDER[2]],
>     ANGLEUNIT["degree",0.01745329252],
>   ID["EPSG",4326]]
>
> According to EPSG, latitude is FIRST. I'm using a cascading WMS (from
> another Geoserver) to put a map behind our GPS station locations and I had
> to switch all the coordinates to make the projections overlay correctly.
>
> -Gavin
>
> --
> Gavin Medley
> Software Engineer I
> *UNAVCO*
> 6350 Nautilus Drive
> Boulder, CO 80301-5394
> med...@unavco.org
>
>
>
> ---------- Forwarded message ----------
> From: Andrea Aime <andrea.a...@geo-solutions.it>
> To: Gavin Medley <med...@unavco.org>
> Cc: Ian Turton <ijtur...@gmail.com>, geoserver-users <
> geoserver-users@lists.sourceforge.net>
> Bcc:
> Date: Tue, 1 Aug 2017 22:49:11 +0200
> Subject: Re: [Geoserver-users] EPSG:4326 Incorrect WKT - Coordinates
> Reversed!
> On Tue, Aug 1, 2017 at 8:09 PM, Gavin Medley <med...@unavco.org> wrote:
>
>> Hi,
>>
>> I'm using 1.1.0. Shouldn't the axis order be defined by the EPSG official
>> WKT string? Am I correct in thinking that order[1] and order[2] specify the
>> coordinate order?
>>
>
> OGC took its dear time to make things clear on this, WFS 1.1 happened
> midway when the axis order storm blew up (and I'm
> partially to blame cause I raised exactly your question, shouldn't WGS84
> be in lat/lon order?).
>
> When that happened everybody on the user side quietly assumed a "sane"
> "east/north" order for everything, in GeoServer we tried to
> keep both parties happy by adopting the following policy
>
> http://docs.geoserver.org/latest/en/user/services/wfs/
> basics.html#axis-ordering
>
> Basically, legacy naming, east/north, new naming, EPSG database suggested
> order instead.
> Deegree seems to have followed suit, https://github.com/
> deegree/deegree3/wiki/Axis-order-handling
>
> There is currently no way to get EPSG suggested axis order with the old
> EPSG:XYWZ syntax, nor any plan to add one
> (but with funding or contribution, that might still happen, as a
> configuration flag for those that want to impose strict behavior).
>
> Mind, the axis order issue is far from being solved, even today and with
> the latest OGC specs:
>
>    - Some outputs only work and make sense in east/north order, and the
>    spec allows no official way to get them (e.g, shapefile, but also, geojson
>    and, hear hear, geopackage, and by spec too, see https://github.com/
>    opengeospatial/geopackage/issues/54
>    <https://github.com/opengeospatial/geopackage/issues/54>)
>    - I'm constantly asked by customers how the heck one can get
>    east/north data out of the latest specs (thankfully we have a way)
>    - Large installations on big companies guide their users to force a
>    lon/lat order, see for example https://dgcsportal.
>    readme.io/docs/web-feature-service
>    <https://dgcsportal.readme.io/docs/web-feature-service>
>    - Some epic blog posts raised the issue among disgruntled people:
>    http://dmorissette.blogspot.it/2012/12/dont-
>    upgrade-to-wms-130-unless-you.html
>    
> <http://dmorissette.blogspot.it/2012/12/dont-upgrade-to-wms-130-unless-you.html>
>
> Long story short, in these conditions, it's best not to take sides and
> allow both desired behaviors (in the two different camps) to happen.
> If you're in the "pure OGC" camp feel free to contribute an extra
> configuration flag to get your GeoServer installation to force EPSG order
> no matter what the syntax is, it will be welcomed (by some, at least :-p ).
> See a guide to get new features in here: https://github.com/
> geoserver/geoserver/wiki/Successfully-requesting-and-
> integrating-new-features-and-improvements-in-GeoServer
>
> Hopefully one day OGC will wake up and realize that depending on the
> context and background both axis orders make sense/are needed, and will
> create a syntax allowing to advertise the order without assuming a local,
> or network accessible copy of the EPSG database, and an official way to ask
> the data in the preferred order.
>
> Hope this helps
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines: http://geoserver.org/comm/
> userlist-guidelines.html
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>


-- 
Gavin Medley
Software Engineer I
*UNAVCO*
6350 Nautilus Drive
Boulder, CO 80301-5394
med...@unavco.org
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to