Re: [Geotools-devel] axis order blues

2015-03-02 Thread Niels Charlier 
Jeroen hit the nail on the head... Users want the ability to choose.. 
but they also want predictability, I would say the latter is even a 
prerequisite for the first. Axis order behaviour and which db system to 
use are orthogonal choices for users. Using a different CRS database 
system should never change axis order behaviour and the documentation 
should always be respected.


Regards
Niels

On 02-03-15 07:52, Dries Jeroen wrote:
Quite a coincidence, I've also been wrestling with axis order last 
week, and also found that the documentation did not appear to be 
correct! The way I expect it to work is for gt-epsg-wkt to be a drop 
in replacement for gt-epsg-hsql, so no difference in axis order, I 
think it's confusing enough as it is. The original reason I personally 
started to use the wkt version is a dependency conflict with hsqldb, I 
also continued to use it because if I use Geotools for instance on 
Hadoop, it sometimes creates a lot of short living processes, and I 
don't want it to do this database setup. Also note that I generally 
only use a couple of predefined reference systems, so there's no need 
to have the full DB.


I would also suggest that we at least try to keep the axis order 
consistent if you use the long form, as that is what most people in 
the OGC community are doing. If a major implementation like 
geotools/geoserver starts to deviate from this in certain 
implementations, than we're back to where we started in the whole axis 
order mess.


best regards,
Jeroen

Jeroen Dries
*TAP* - Centre for Remote Sensing and Earth Observation Processes
VITO NV | Boeretang 200 | 2400 Mol
tel. +32 14 33 55 11 | jeroen.dr...@vito.be <mailto:voornaam.n...@vito.be>
cid:image001.jpg@01CDCE3A.4E197A50 
<http://www.vito.be/>cid:image001.jpg@01CD3F0D.B57AA190 
<http://www.linkedin.com/company/17947>cid:image003.jpg@01CD3F0D.B57AA190 
<http://twitter.com/#%21/vitobelgium>cid:image002.jpg@01CD3F0D.B57AA190 <https://www.facebook.com/VITObelgium>


*Van:* andrea.a...@gmail.com [andrea.a...@gmail.com] namens Andrea 
Aime [andrea.a...@geo-solutions.it]

*Verzonden:* vrijdag 27 februari 2015 12:55
*Aan:* Niels Charlier; Dries Jeroen
*CC:* Ben Caradoc-Davies; geotools-devel@lists.sourceforge.net; Jody 
Garnett

*Onderwerp:* Re: [Geotools-devel] axis order blues

On Fri, Feb 27, 2015 at 12:34 PM, Niels Charlier <mailto:ni...@scitus.be>> wrote:



On 27-02-15 11:52, Andrea Aime wrote:

On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier mailto:ni...@scitus.be>> wrote:

Hmm yeah I figured it had something to do with that. Thanks
for the
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to
produce the
wrong CRS in the first place?


As far as I remember gt-espg-wkt always had east/north
orientation in all CRS,
and people keep on using it like this.
I'm afraid changing the axis order now would break all existing
users of
this module (e.g., I know of GeoServer customizations that use it
instead of
epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually
want everything
east/north)


Isn't it unlikely that those users use the URI syntax. The
geotools documentation claims that when you use the URI syntax the
result is always perfectly predictable... quod non.


As said, there are customized GeoServer versions using it, so the use 
of URI syntax is highly likely.
Jeroen, I believe you're doing that right? Using epsg-wkt in GeoServer 
instead of gt-espg-hsql?
Can you talk about how you're using it, context and so on, also 
related to axis flipping?


Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

Re: [Geotools-devel] axis order blues

2015-03-02 Thread Andrea Aime 
On Mon, Mar 2, 2015 at 12:22 PM, Niels Charlier  wrote:

>  Jeroen hit the nail on the head... Users want the ability to choose.. but
> they also want predictability, I would say the latter is even a
> prerequisite for the first. Axis order behaviour and which db system to use
> are orthogonal choices for users. Using a different CRS database system
> should never change axis order behaviour and the documentation should
> always be respected.
>

I see your point, but to fix it, we will break backwards compatibility for
those that were happily using gt-epsg-wkt until today.

If you two want to keep it going and change its default axis order, I have
no
particular objections, provided you become maintainers of the module, keep
it up to date in the future,
and personally handle the users that will be bitten by this change.

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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.

---
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-03-01 Thread Andrea Aime 
On Mon, Mar 2, 2015 at 7:52 AM, Dries Jeroen  wrote:

>  Quite a coincidence, I've also been wrestling with axis order last week,
> and also found that the documentation did not appear to be correct! The way
> I expect it to work is for gt-epsg-wkt to be a drop in replacement for
> gt-epsg-hsql, so no difference in axis order, I think it's confusing enough
> as it is. The original reason I personally started to use the wkt version
> is a dependency conflict with hsqldb, I also continued to use it because if
> I use Geotools for instance on Hadoop, it sometimes creates a lot of short
> living processes, and I don't want it to do this database setup. Also note
> that I generally only use a couple of predefined reference systems, so
> there's no need to have the full DB.
>
> I would also suggest that we at least try to keep the axis order
> consistent if you use the long form, as that is what most people in the OGC
> community are doing. If a major implementation like geotools/geoserver
> starts to deviate from this in certain implementations, than we're back to
> where we started in the whole axis order mess.
>

The issue is... gt-epsg-wkt has always been like this, and originally
geoserver was using it instead of gt-epsg-hsql.
When OGC started the axis order mess we were forced to switch to
gt-epsg-hsql in order to offer both orientations,
and gt-epsg-wkt was retained for those that did want a simpler setup (there
is actually more, the hsql database
contains also alternative algorithms for datum shifts that can be enabled
when you have grid files, which are not
available with the gt-epsg-wkt one, due to syntax limitations).

Actually no major program out there is using it (none of those contributing
to GeoTools at least) so as far as
we are concerned, we could just drop it, it's there only for backwards
compatibility sake

Cheers
Andrea


-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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.

---
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-03-01 Thread Dries Jeroen 
Quite a coincidence, I've also been wrestling with axis order last week, and 
also found that the documentation did not appear to be correct! The way I 
expect it to work is for gt-epsg-wkt to be a drop in replacement for 
gt-epsg-hsql, so no difference in axis order, I think it's confusing enough as 
it is. The original reason I personally started to use the wkt version is a 
dependency conflict with hsqldb, I also continued to use it because if I use 
Geotools for instance on Hadoop, it sometimes creates a lot of short living 
processes, and I don't want it to do this database setup. Also note that I 
generally only use a couple of predefined reference systems, so there's no need 
to have the full DB.

I would also suggest that we at least try to keep the axis order consistent if 
you use the long form, as that is what most people in the OGC community are 
doing. If a major implementation like geotools/geoserver starts to deviate from 
this in certain implementations, than we're back to where we started in the 
whole axis order mess.

best regards,
Jeroen

Jeroen Dries
TAP - Centre for Remote Sensing and Earth Observation Processes
VITO NV | Boeretang 200 | 2400 Mol
tel. +32 14 33 55 11 | jeroen.dr...@vito.be<mailto:voornaam.n...@vito.be>
[cid:image001.jpg@01CDCE3A.4E197A50]<http://www.vito.be/>[cid:image001.jpg@01CD3F0D.B57AA190]<http://www.linkedin.com/company/17947>[cid:image003.jpg@01CD3F0D.B57AA190]<http://twitter.com/#!/vitobelgium>[cid:image002.jpg@01CD3F0D.B57AA190]<https://www.facebook.com/VITObelgium>

Van: andrea.a...@gmail.com [andrea.a...@gmail.com] namens Andrea Aime 
[andrea.a...@geo-solutions.it]
Verzonden: vrijdag 27 februari 2015 12:55
Aan: Niels Charlier; Dries Jeroen
CC: Ben Caradoc-Davies; geotools-devel@lists.sourceforge.net; Jody Garnett
Onderwerp: Re: [Geotools-devel] axis order blues

On Fri, Feb 27, 2015 at 12:34 PM, Niels Charlier 
mailto:ni...@scitus.be>> wrote:

On 27-02-15 11:52, Andrea Aime wrote:
On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier 
mailto:ni...@scitus.be>> wrote:
Hmm yeah I figured it had something to do with that. Thanks for the
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to produce the
wrong CRS in the first place?

As far as I remember gt-espg-wkt always had east/north orientation in all CRS,
and people keep on using it like this.
I'm afraid changing the axis order now would break all existing users of
this module (e.g., I know of GeoServer customizations that use it instead of
epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually want everything
east/north)

Isn't it unlikely that those users use the URI syntax. The geotools 
documentation claims that when you use the URI syntax the result is always 
perfectly predictable... quod non.

As said, there are customized GeoServer versions using it, so the use of URI 
syntax is highly likely.
Jeroen, I believe you're doing that right? Using epsg-wkt in GeoServer instead 
of gt-espg-hsql?
Can you talk about how you're using it, context and so on, also related to axis 
flipping?

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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 b

Re: [Geotools-devel] axis order blues

2015-02-27 Thread Andrea Aime 
On Fri, Feb 27, 2015 at 12:34 PM, Niels Charlier  wrote:

>
> On 27-02-15 11:52, Andrea Aime wrote:
>
>  On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier  wrote:
>
>> Hmm yeah I figured it had something to do with that. Thanks for the
>> detailed explanation, Ben.
>> But my question remains: should gt-epsg-wkt be allowed to produce the
>> wrong CRS in the first place?
>>
>
>  As far as I remember gt-espg-wkt always had east/north orientation in
> all CRS,
> and people keep on using it like this.
> I'm afraid changing the axis order now would break all existing users of
> this module (e.g., I know of GeoServer customizations that use it instead
> of
> epsg-hsql because they don't want databases to be created around, and
> they don't give a damn about OGC/EPSG axis order, they actually want
> everything
> east/north)
>
>   Isn't it unlikely that those users use the URI syntax. The geotools
> documentation claims that when you use the URI syntax the result is always
> perfectly predictable... quod non.
>

As said, there are customized GeoServer versions using it, so the use of
URI syntax is highly likely.
Jeroen, I believe you're doing that right? Using epsg-wkt in GeoServer
instead of gt-espg-hsql?
Can you talk about how you're using it, context and so on, also related to
axis flipping?

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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.

---
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-02-27 Thread Niels Charlier 


On 27-02-15 11:52, Andrea Aime wrote:
On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier > wrote:


Hmm yeah I figured it had something to do with that. Thanks for the
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to produce the
wrong CRS in the first place?


As far as I remember gt-espg-wkt always had east/north orientation in 
all CRS,

and people keep on using it like this.
I'm afraid changing the axis order now would break all existing users of
this module (e.g., I know of GeoServer customizations that use it 
instead of

epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually want 
everything

east/north)

Isn't it unlikely that those users use the URI syntax. The geotools 
documentation claims that when you use the URI syntax the result is 
always perfectly predictable... quod non.


Regards
Niels
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-02-27 Thread Andrea Aime 
On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier  wrote:

> Hmm yeah I figured it had something to do with that. Thanks for the
> detailed explanation, Ben.
> But my question remains: should gt-epsg-wkt be allowed to produce the
> wrong CRS in the first place?
>

As far as I remember gt-espg-wkt always had east/north orientation in all
CRS,
and people keep on using it like this.
I'm afraid changing the axis order now would break all existing users of
this module (e.g., I know of GeoServer customizations that use it instead
of
epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually want
everything
east/north)

Cheers
Andrea



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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.

---
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-02-27 Thread Niels Charlier 
Hmm yeah I figured it had something to do with that. Thanks for the 
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to produce the 
wrong CRS in the first place?
Should it perhaps not be completely removed from all dependencies and 
replaced by better alternatives

Regards
Niels

On 27-02-15 01:04, Ben Caradoc-Davies wrote:
> Niels,
>
> I will answer your first question. You are right: this is a classpath 
> difference. The cause is that Maven and Eclipse have different 
> dependency models. Eclipse has no notion of a phase (compile versus 
> test) and no way to exclude transitive dependencies (so test 
> dependencies of other modules always get included on the classpath). 
> gt-epsg-wkt is the problem; how do you make it go away?
>
> This is the devious workaround I implemented in 2010 to disable 
> gt-epsg-wkt EPSGCRSAuthorityFactory so that gt-xsd-gml3 unit tests 
> pass in Eclipse:
> https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/referencing/crs/EPSGCRSAuthorityFactory.java
>  
>
> https://jira.codehaus.org/browse/GEOT-3112
>
> It may be enough to add gt-xsd-gml3 as a test-phase dependency before 
> all other dependencies. Maven will not include it as a dependency for 
> consumers of your module because it is test-phase only. Eclipse will 
> blindly include it at all times and disable gt-epsg-wkt.
>
> There is no META-INF/services SPI file as this is provided by the real 
> implementations.
>
> Kind regards,
> Ben.
>
> On 27/02/15 10:52, Niels Charlier wrote:
>> Hi,
>>
>> Okay, so according to the geotools documentation CRSes with full URI
>> specification don't suffer from axis order confusions. But I have the
>> following SRS used in a test:
>> urn:x-ogc:def:crs:EPSG:6.11.2:26713
>> And here's the thing: when running the test in maven, this is
>> North->East, when running the same test in eclipse this is East->North.
>> How on earth could that be possible?? What I've been able to figure out
>> is that when running in maven the CRS is built by DirectEpsgFactory
>> which takes it from a database in epsg-hsql, but in eclipse it is built
>> by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file
>> (which says east-north). So my guess is that this has something to do
>> with the different way that maven and eclipse handle module
>> dependencies. But still, shouldn't it always be North->East when
>> specified with such a URI?
>>
>> It almost seems like a pure gamble which axis order you are going to end
>> up with in geotools. You can force geotools to always use east->north,
>> but you can't do it the other way around! And you can only set that
>> setting once in the beginning of running your java instance, changing it
>> again doesn't guarantee success because of caching crses.
>>
>> Also, I think there is a lot of unnecessary throwing away of axis order
>> going on by using srs strings when there are already methods in place to
>> use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs
>> methods are deprecated, but they are still used everywhere, even in new
>> code, it seems like the deprecations in BoundingBoxImpl are still
>> ignored. In the FilterDuplicatorVisitor, from which most filter visitors
>> are derived, the boundingbox is rebuilt using setSrs() so all CRS
>> information axis order is lost each time a filter is rebuilt with a
>> visitor. I think that could be easily changed.
>>
>>
>>
>> Regards
>> Niels
>>
>> --
>>  
>>
>> Dive into the World of Parallel Programming The Go Parallel Website, 
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your 
>> hub for all
>> things parallel software development, from weekly thought leadership 
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

2015-02-26 Thread Ben Caradoc-Davies 
Niels,

I will answer your first question. You are right: this is a classpath 
difference. The cause is that Maven and Eclipse have different 
dependency models. Eclipse has no notion of a phase (compile versus 
test) and no way to exclude transitive dependencies (so test 
dependencies of other modules always get included on the classpath). 
gt-epsg-wkt is the problem; how do you make it go away?

This is the devious workaround I implemented in 2010 to disable 
gt-epsg-wkt EPSGCRSAuthorityFactory so that gt-xsd-gml3 unit tests pass 
in Eclipse:
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/referencing/crs/EPSGCRSAuthorityFactory.java
https://jira.codehaus.org/browse/GEOT-3112

It may be enough to add gt-xsd-gml3 as a test-phase dependency before 
all other dependencies. Maven will not include it as a dependency for 
consumers of your module because it is test-phase only. Eclipse will 
blindly include it at all times and disable gt-epsg-wkt.

There is no META-INF/services SPI file as this is provided by the real 
implementations.

Kind regards,
Ben.

On 27/02/15 10:52, Niels Charlier wrote:
> Hi,
>
> Okay, so according to the geotools documentation CRSes with full URI
> specification don't suffer from axis order confusions. But I have the
> following SRS used in a test:
> urn:x-ogc:def:crs:EPSG:6.11.2:26713
> And here's the thing: when running the test in maven, this is
> North->East, when running the same test in eclipse this is East->North.
> How on earth could that be possible?? What I've been able to figure out
> is that when running in maven the CRS is built by DirectEpsgFactory
> which takes it from a database in epsg-hsql, but in eclipse it is built
> by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file
> (which says east-north). So my guess is that this has something to do
> with the different way that maven and eclipse handle module
> dependencies. But still, shouldn't it always be North->East when
> specified with such a URI?
>
> It almost seems like a pure gamble which axis order you are going to end
> up with in geotools. You can force geotools to always use east->north,
> but you can't do it the other way around! And you can only set that
> setting once in the beginning of running your java instance, changing it
> again doesn't guarantee success because of caching crses.
>
> Also, I think there is a lot of unnecessary throwing away of axis order
> going on by using srs strings when there are already methods in place to
> use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs
> methods are deprecated, but they are still used everywhere, even in new
> code, it seems like the deprecations in BoundingBoxImpl are still
> ignored. In the FilterDuplicatorVisitor, from which most filter visitors
> are derived, the boundingbox is rebuilt using setSrs() so all CRS
> information axis order is lost each time a filter is rebuilt with a
> visitor. I think that could be easily changed.
>
>
>
> Regards
> Niels
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>

-- 
Ben Caradoc-Davies 
Software Engineer
Transient Software 
New Zealand

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] axis order blues

2015-02-26 Thread Niels Charlier 
Hi,

Okay, so according to the geotools documentation CRSes with full URI 
specification don't suffer from axis order confusions. But I have the 
following SRS used in a test:
urn:x-ogc:def:crs:EPSG:6.11.2:26713
And here's the thing: when running the test in maven, this is 
North->East, when running the same test in eclipse this is East->North. 
How on earth could that be possible?? What I've been able to figure out 
is that when running in maven the CRS is built by DirectEpsgFactory 
which takes it from a database in epsg-hsql, but in eclipse it is built 
by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file 
(which says east-north). So my guess is that this has something to do 
with the different way that maven and eclipse handle module 
dependencies. But still, shouldn't it always be North->East when 
specified with such a URI?

It almost seems like a pure gamble which axis order you are going to end 
up with in geotools. You can force geotools to always use east->north, 
but you can't do it the other way around! And you can only set that 
setting once in the beginning of running your java instance, changing it 
again doesn't guarantee success because of caching crses.

Also, I think there is a lot of unnecessary throwing away of axis order 
going on by using srs strings when there are already methods in place to 
use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs 
methods are deprecated, but they are still used everywhere, even in new 
code, it seems like the deprecations in BoundingBoxImpl are still 
ignored. In the FilterDuplicatorVisitor, from which most filter visitors 
are derived, the boundingbox is rebuilt using setSrs() so all CRS 
information axis order is lost each time a filter is rebuilt with a 
visitor. I think that could be easily changed.



Regards
Niels

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel