Hi Ben,
Hmm, that is certainly the behavior. So the st_makepoint function doesn't
enforce it upon point creation but other postgis functions do expect (lon,
lat). In the context of Geoserver, it is also not enforced is that correct?
My observation is that Geoserver will happily take my (lat, lon) geometry
and project it, mirrored (I've since fixed my database though). Not sure
what it does with the values that are out of bounds.
On Wed, Aug 16, 2017 at 3:33 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:
> Gavin,
>
> you might think that you have tables with geometries with lat/lon axis
> order, but I suspect that, as soon as you try to reproject, you will
> discover that postgis does not agree.
>
> Try transforming your office location in WGS 84 to NAD83(2011) / Colorado
> Central (eastings/northings in metres):
>
> lat/lon axis order:
>
> test=> select st_asewkt(st_transform(st_setsrid(st_makepoint(40.061165,
> -105.205885), 4326), 6427));
> ERROR: transform: couldn't project point (40.0612 -105.206 0): latitude
> or longitude exceeded limits (-14)
>
> lon/lat axis order:
>
> test=> select st_asewkt(st_transform(st_setsrid(st_makepoint(-105.205885,
> 40.061165), 4326), 6427));
> st_asewkt
> ---------------------------------------------------
> SRID=6427;POINT(939496.893326505 552163.38163549)
> (1 row)
>
> Kind regards,
> Ben.
>
>
> On 17/08/17 06:57, Gavin Medley wrote:
>
>> 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,LENG
>>>>> THUNIT["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
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>>
>>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>
--
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
