Hi Jukka,
You are right about the note obviously. That is definitely not enforced by
the function in any way though so I think it's a convention but not a
requirement. I know because I have tables with geometries in the format
(lat, lon) and the data is preserved.
This is a long standing debate and I don't think it will be resolved any
time soon. I think we can probably close this thread.
On Wed, Aug 16, 2017 at 12:47 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Hi,
>
>
> The link you provided actually shows this information:
>
> geometry *ST_MakePoint*(double precision x, double precision y);
>
> and
>
> Note x is longitude and y is latitude
>
>
> I would rather say that the function is agnostic to the EPSG specification
> for the given SRID because it requires always longitude-latitude /
> easting-northing order.
>
>
> -Jukka Rahkonen-
>
>
> ------------------------------
> *Lähettäjä:* Gavin Medley <med...@unavco.org>
> *Lähetetty:* 16. elokuuta 2017 21:21
> *Vastaanottaja:* Andrea Aime
> *Kopio:* GeoServer Mailing List List; Rahkonen Jukka (MML)
> *Aihe:* Re: [Geoserver-users] EPSG:4326 Incorrect WKT - Coordinates
> Reversed!
>
> Hi Andrea,
>
> Maybe we are thinking of different ways of storing the data. To make the
> Point geometries I'm using ST_SetSRID(ST_MakePoint(lat, lon), 4326) as
> documented here:
> https://postgis.net/docs/ST_MakePoint.html
> I think the function is agnostic as to the actual values entered so it's
> up to the user to ensure that the order and values match the EPSG
> specification for the given SRID.
>
> On Wed, Aug 16, 2017 at 11:49 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> Ah!
>> As far as I know postgis, Oracle spatial, SQL server all require data to
>> be stored as east/north no matter what the CRS is
>>
>> Cheers
>> Andrea
>>
>> Il 16 ago 2017 11:08 AM, "Gavin Medley" <med...@unavco.org> ha scritto:
>>
>> 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/deegr
>>> ee/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.rea
>>> dme.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/geose
>>> rver/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
>>
>>
>>
>
>
> --
> Gavin Medley
> Software Engineer I
> *UNAVCO*
> 6350 Nautilus Drive
> Boulder, CO 80301-5394
> med...@unavco.org
>
>
--
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
