You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(23) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(8) |
Feb
(11) |
Mar
(14) |
Apr
(21) |
May
(43) |
Jun
(25) |
Jul
(19) |
Aug
(23) |
Sep
(26) |
Oct
(27) |
Nov
(46) |
Dec
(13) |
2004 |
Jan
(34) |
Feb
(20) |
Mar
(17) |
Apr
(18) |
May
(58) |
Jun
(64) |
Jul
(86) |
Aug
(50) |
Sep
(67) |
Oct
(124) |
Nov
(83) |
Dec
(159) |
2005 |
Jan
(127) |
Feb
(127) |
Mar
(133) |
Apr
(113) |
May
(113) |
Jun
(176) |
Jul
(182) |
Aug
(156) |
Sep
(138) |
Oct
(182) |
Nov
(148) |
Dec
(130) |
2006 |
Jan
(156) |
Feb
(158) |
Mar
(170) |
Apr
(114) |
May
(145) |
Jun
(135) |
Jul
(85) |
Aug
(163) |
Sep
(170) |
Oct
(180) |
Nov
(167) |
Dec
(124) |
2007 |
Jan
(133) |
Feb
(200) |
Mar
(193) |
Apr
(237) |
May
(154) |
Jun
(140) |
Jul
(199) |
Aug
(331) |
Sep
(123) |
Oct
(95) |
Nov
(125) |
Dec
(194) |
2008 |
Jan
(162) |
Feb
(148) |
Mar
(143) |
Apr
(207) |
May
(207) |
Jun
(231) |
Jul
(225) |
Aug
(178) |
Sep
(141) |
Oct
(201) |
Nov
(146) |
Dec
(124) |
2009 |
Jan
(232) |
Feb
(264) |
Mar
(213) |
Apr
(215) |
May
(153) |
Jun
(244) |
Jul
(71) |
Aug
(124) |
Sep
(247) |
Oct
(278) |
Nov
(155) |
Dec
(178) |
2010 |
Jan
(203) |
Feb
(133) |
Mar
(338) |
Apr
(226) |
May
(386) |
Jun
(385) |
Jul
(146) |
Aug
(162) |
Sep
(172) |
Oct
(72) |
Nov
(69) |
Dec
(96) |
2011 |
Jan
(63) |
Feb
(112) |
Mar
(235) |
Apr
(198) |
May
(260) |
Jun
(239) |
Jul
(309) |
Aug
(186) |
Sep
(140) |
Oct
(174) |
Nov
(105) |
Dec
(41) |
2012 |
Jan
(68) |
Feb
(132) |
Mar
(89) |
Apr
(61) |
May
(113) |
Jun
(129) |
Jul
(62) |
Aug
(144) |
Sep
(94) |
Oct
(116) |
Nov
(151) |
Dec
(57) |
2013 |
Jan
(101) |
Feb
(144) |
Mar
(93) |
Apr
(75) |
May
(67) |
Jun
(52) |
Jul
(64) |
Aug
(67) |
Sep
(65) |
Oct
(55) |
Nov
(26) |
Dec
(32) |
2014 |
Jan
(38) |
Feb
(40) |
Mar
(40) |
Apr
(43) |
May
(28) |
Jun
(50) |
Jul
(79) |
Aug
(90) |
Sep
(75) |
Oct
(45) |
Nov
(62) |
Dec
(49) |
2015 |
Jan
(40) |
Feb
(64) |
Mar
(80) |
Apr
(43) |
May
(49) |
Jun
(46) |
Jul
(23) |
Aug
(69) |
Sep
(49) |
Oct
(61) |
Nov
(43) |
Dec
(33) |
2016 |
Jan
(15) |
Feb
(63) |
Mar
(40) |
Apr
(56) |
May
(43) |
Jun
(35) |
Jul
(41) |
Aug
(35) |
Sep
(10) |
Oct
(41) |
Nov
(39) |
Dec
(37) |
2017 |
Jan
(57) |
Feb
(19) |
Mar
(36) |
Apr
(8) |
May
(19) |
Jun
(17) |
Jul
(9) |
Aug
(18) |
Sep
(19) |
Oct
(17) |
Nov
(4) |
Dec
(13) |
2018 |
Jan
(17) |
Feb
(15) |
Mar
(23) |
Apr
(22) |
May
(5) |
Jun
(3) |
Jul
(30) |
Aug
(10) |
Sep
(20) |
Oct
(12) |
Nov
(1) |
Dec
(9) |
2019 |
Jan
(13) |
Feb
(19) |
Mar
(34) |
Apr
(16) |
May
(14) |
Jun
(10) |
Jul
(21) |
Aug
(25) |
Sep
(22) |
Oct
(3) |
Nov
(10) |
Dec
(8) |
2020 |
Jan
|
Feb
(19) |
Mar
(3) |
Apr
(51) |
May
(5) |
Jun
(12) |
Jul
(16) |
Aug
(15) |
Sep
(7) |
Oct
(16) |
Nov
(24) |
Dec
(24) |
2021 |
Jan
(11) |
Feb
(27) |
Mar
(14) |
Apr
(14) |
May
(3) |
Jun
(11) |
Jul
(8) |
Aug
(8) |
Sep
(15) |
Oct
(24) |
Nov
(11) |
Dec
(2) |
2022 |
Jan
(6) |
Feb
(14) |
Mar
(1) |
Apr
(9) |
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
(17) |
Oct
(5) |
Nov
(15) |
Dec
(4) |
2023 |
Jan
(7) |
Feb
(16) |
Mar
(9) |
Apr
(13) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(3) |
Sep
(3) |
Oct
(13) |
Nov
(4) |
Dec
(8) |
2024 |
Jan
(9) |
Feb
(10) |
Mar
(6) |
Apr
(3) |
May
(7) |
Jun
(7) |
Jul
(7) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Jody G. <jod...@gm...> - 2024-08-04 22:46:38
|
We use our own referencing library, not gdal and proj - - Jody Garnett On Sun, Aug 4, 2024 at 2:21 PM Phil Scadden <P.S...@gn...> wrote: > Looking closer at that, the osr refers to _osr which is python binding a > GDAL C++ class. There are java binding to the same class > https://gdal.org/java/org/gdal/osr/SpatialReference.html > > > > *From:* Mourad HARMIM <mou...@li...> > *Sent:* Friday, August 2, 2024 12:05 AM > *To:* Ian Turton <ijt...@gm...> > *Cc:* geo...@li...; > geo...@li... > *Subject:* Re: [Geotools-devel] Help with GeoTools : Trouble transforming > coordinates > > > > > > *CAUTION:* This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe: > > Hello Ian, > > Thank you for your reply. > > Unfortunatly a was unable to find a corresponding grid shift nor the right > parameters for this specific transformation. > > > > What is suprising is epsg.io online transformer it is actually possible > to do it : Transform coordinates - GPS online converter (epsg.io) > <https://epsg.io/transform#s_srs=27572&t_srs=2154&x=601218.2709050&y=2428184.1367070> > > > > I found the source code of epsg.io and they implemented the > transformation using "osr" library in python : epsg.io/app.py at master · > maptiler/epsg.io · GitHub > <https://github.com/maptiler/epsg.io/blob/master/app.py#L1380> > > > > However I could not find anything similair in java. > > > > Kind regards, > > Mourad Harmim. > ------------------------------ > > *De :* Ian Turton <ijt...@gm...> > *Envoyé :* jeudi 1 août 2024 10:32 > *À :* Mourad HARMIM <mou...@li...> > *Cc :* geo...@li... < > geo...@li...>; > geo...@li... <geo...@li... > > > *Objet :* Re: [Geotools-devel] Help with GeoTools : Trouble transforming > coordinates > > > > From a quick look on epsg.io there seems not to be a direct transform > from *27572 *to* 2154 *so that is why the TOWGS or Bursa Wolf transform > is needed. These would appear to have a 2m accuracy so some transformation > error is to be expected. > > > > If you have a grid shift or other transformation file available then you > can add it to GeoTools as described here - > https://gis.stackexchange.com/questions/313512/specifying-epsg-transformation-method-in-geotools/313523#313523 > > > > Ian > > > > > > On Mon, 15 Jul 2024 at 01:31, Mourad HARMIM <mou...@li...> wrote: > > Hello everyone, > I hope this message finds you well. > > > My name is Mourad Harmim, a Data Engineer consultant from France. > Still getting used to GeoTools, I’m facing an issue when I try to > transform coordinates from *Lambert 2 extended (EPSG :27572) to Lambert > 93 (EPSE :2154).* > > Here is my current situation : > > · When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > false)* there is an error telling that Bursa Wolf parameters are missing > > · When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > true)* I get coordinates but they seem inaccurate (I guess it is about a > missing grid shift) > > · When I use intermediate system : *Lambert 2 extended > (EPSG :27572) to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154)* I get > better results but still inaccurate. > > > > I would like to know what it is the correct approch to have an accurate > transformation between these two systems. > > > > I hope that it is not inappropriate to ask for your help through this > email and I hope to hear from you soon. > Thank you. > Mourad Harmim. > > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > > Ian Turton > Notice: This email and any attachments are confidential and may not be > used, published or redistributed without the prior written consent of the > Institute of Geological and Nuclear Sciences Limited (GNS Science). If > received in error please destroy and immediately notify GNS Science. Do not > copy or disclose the contents. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Phil S. <P.S...@gn...> - 2024-08-04 21:21:10
|
Looking closer at that, the osr refers to _osr which is python binding a GDAL C++ class. There are java binding to the same class https://gdal.org/java/org/gdal/osr/SpatialReference.html From: Mourad HARMIM <mou...@li...> Sent: Friday, August 2, 2024 12:05 AM To: Ian Turton <ijt...@gm...> Cc: geo...@li...; geo...@li... Subject: Re: [Geotools-devel] Help with GeoTools : Trouble transforming coordinates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe: Hello Ian, Thank you for your reply. Unfortunatly a was unable to find a corresponding grid shift nor the right parameters for this specific transformation. What is suprising is epsg.io online transformer it is actually possible to do it : Transform coordinates - GPS online converter (epsg.io)<https://epsg.io/transform#s_srs=27572&t_srs=2154&x=601218.2709050&y=2428184.1367070> I found the source code of epsg.io and they implemented the transformation using "osr" library in python : epsg.io/app.py at master · maptiler/epsg.io · GitHub<https://github.com/maptiler/epsg.io/blob/master/app.py#L1380> However I could not find anything similair in java. Kind regards, Mourad Harmim. ________________________________ De : Ian Turton <ijt...@gm...<mailto:ijt...@gm...>> Envoyé : jeudi 1 août 2024 10:32 À : Mourad HARMIM <mou...@li...<mailto:mou...@li...>> Cc : geo...@li...<mailto:geo...@li...> <geo...@li...<mailto:geo...@li...>>; geo...@li...<mailto:geo...@li...> <geo...@li...<mailto:geo...@li...>> Objet : Re: [Geotools-devel] Help with GeoTools : Trouble transforming coordinates >From a quick look on epsg.io<http://epsg.io> there seems not to be a direct transform from 27572 to 2154 so that is why the TOWGS or Bursa Wolf transform is needed. These would appear to have a 2m accuracy so some transformation error is to be expected. If you have a grid shift or other transformation file available then you can add it to GeoTools as described here - https://gis.stackexchange.com/questions/313512/specifying-epsg-transformation-method-in-geotools/313523#313523 Ian On Mon, 15 Jul 2024 at 01:31, Mourad HARMIM <mou...@li...<mailto:mou...@li...>> wrote: Hello everyone, I hope this message finds you well. My name is Mourad Harmim, a Data Engineer consultant from France. Still getting used to GeoTools, I'm facing an issue when I try to transform coordinates from Lambert 2 extended (EPSG :27572) to Lambert 93 (EPSE :2154). Here is my current situation : · When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), false) there is an error telling that Bursa Wolf parameters are missing · When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), true) I get coordinates but they seem inaccurate (I guess it is about a missing grid shift) · When I use intermediate system : Lambert 2 extended (EPSG :27572) to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154) I get better results but still inaccurate. I would like to know what it is the correct approch to have an accurate transformation between these two systems. I hope that it is not inappropriate to ask for your help through this email and I hope to hear from you soon. Thank you. Mourad Harmim. _______________________________________________ GeoTools-Devel mailing list Geo...@li...<mailto:Geo...@li...> https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ian Turton Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents. |
From: Jody G. <jod...@gm...> - 2024-08-03 13:26:40
|
I you are keen to implement a new transform it would be a lovely addition to the library? What is the license on your Python example? You can see other implementations in the library as an example. - - Jody Garnett On Thu, Aug 1, 2024 at 6:12 AM Mourad HARMIM <mou...@li...> wrote: > Hello Ian, > Thank you for your reply. > Unfortunatly a was unable to find a corresponding grid shift nor the right > parameters for this specific transformation. > > What is suprising is epsg.io online transformer it is actually possible > to do it : Transform coordinates - GPS online converter (epsg.io) > <https://epsg.io/transform#s_srs=27572&t_srs=2154&x=601218.2709050&y=2428184.1367070> > > I found the source code of epsg.io and they implemented the > transformation using "osr" library in python : epsg.io/app.py at master · > maptiler/epsg.io · GitHub > <https://github.com/maptiler/epsg.io/blob/master/app.py#L1380> > > However I could not find anything similair in java. > > Kind regards, > Mourad Harmim. > ------------------------------ > *De :* Ian Turton <ijt...@gm...> > *Envoyé :* jeudi 1 août 2024 10:32 > *À :* Mourad HARMIM <mou...@li...> > *Cc :* geo...@li... < > geo...@li...>; > geo...@li... <geo...@li... > > > *Objet :* Re: [Geotools-devel] Help with GeoTools : Trouble transforming > coordinates > > From a quick look on epsg.io there seems not to be a direct transform > from *27572 *to* 2154 *so that is why the TOWGS or Bursa Wolf transform > is needed. These would appear to have a 2m accuracy so some transformation > error is to be expected. > > If you have a grid shift or other transformation file available then you > can add it to GeoTools as described here - > https://gis.stackexchange.com/questions/313512/specifying-epsg-transformation-method-in-geotools/313523#313523 > > Ian > > > On Mon, 15 Jul 2024 at 01:31, Mourad HARMIM <mou...@li...> wrote: > > Hello everyone, > I hope this message finds you well. > > My name is Mourad Harmim, a Data Engineer consultant from France. > Still getting used to GeoTools, I’m facing an issue when I try to > transform coordinates from *Lambert 2 extended (EPSG :27572) to Lambert > 93 (EPSE :2154).* > > Here is my current situation : > > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > false)* there is an error telling that Bursa Wolf parameters are > missing > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > true)* I get coordinates but they seem inaccurate (I guess it is about > a missing grid shift) > - When I use intermediate system : *Lambert 2 extended (EPSG :27572) > to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154)* I get better results > but still inaccurate. > > > I would like to know what it is the correct approch to have an accurate > transformation between these two systems. > > I hope that it is not inappropriate to ask for your help through this > email and I hope to hear from you soon. > Thank you. > Mourad Harmim. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > Ian Turton > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Mourad H. <mou...@li...> - 2024-08-01 12:04:55
|
Hello Ian, Thank you for your reply. Unfortunatly a was unable to find a corresponding grid shift nor the right parameters for this specific transformation. What is suprising is epsg.io online transformer it is actually possible to do it : Transform coordinates - GPS online converter (epsg.io)<https://epsg.io/transform#s_srs=27572&t_srs=2154&x=601218.2709050&y=2428184.1367070> I found the source code of epsg.io and they implemented the transformation using "osr" library in python : epsg.io/app.py at master · maptiler/epsg.io · GitHub<https://github.com/maptiler/epsg.io/blob/master/app.py#L1380> However I could not find anything similair in java. Kind regards, Mourad Harmim. ________________________________ De : Ian Turton <ijt...@gm...> Envoyé : jeudi 1 août 2024 10:32 À : Mourad HARMIM <mou...@li...> Cc : geo...@li... <geo...@li...>; geo...@li... <geo...@li...> Objet : Re: [Geotools-devel] Help with GeoTools : Trouble transforming coordinates >From a quick look on epsg.io<http://epsg.io> there seems not to be a direct transform from 27572 to 2154 so that is why the TOWGS or Bursa Wolf transform is needed. These would appear to have a 2m accuracy so some transformation error is to be expected. If you have a grid shift or other transformation file available then you can add it to GeoTools as described here - https://gis.stackexchange.com/questions/313512/specifying-epsg-transformation-method-in-geotools/313523#313523 Ian On Mon, 15 Jul 2024 at 01:31, Mourad HARMIM <mou...@li...<mailto:mou...@li...>> wrote: Hello everyone, I hope this message finds you well. My name is Mourad Harmim, a Data Engineer consultant from France. Still getting used to GeoTools, I’m facing an issue when I try to transform coordinates from Lambert 2 extended (EPSG :27572) to Lambert 93 (EPSE :2154). Here is my current situation : * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), false) there is an error telling that Bursa Wolf parameters are missing * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), true) I get coordinates but they seem inaccurate (I guess it is about a missing grid shift) * When I use intermediate system : Lambert 2 extended (EPSG :27572) to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154) I get better results but still inaccurate. I would like to know what it is the correct approch to have an accurate transformation between these two systems. I hope that it is not inappropriate to ask for your help through this email and I hope to hear from you soon. Thank you. Mourad Harmim. _______________________________________________ GeoTools-Devel mailing list Geo...@li...<mailto:Geo...@li...> https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ian Turton |
From: Ian T. <ijt...@gm...> - 2024-08-01 08:32:58
|
>From a quick look on epsg.io there seems not to be a direct transform from *27572 *to* 2154 *so that is why the TOWGS or Bursa Wolf transform is needed. These would appear to have a 2m accuracy so some transformation error is to be expected. If you have a grid shift or other transformation file available then you can add it to GeoTools as described here - https://gis.stackexchange.com/questions/313512/specifying-epsg-transformation-method-in-geotools/313523#313523 Ian On Mon, 15 Jul 2024 at 01:31, Mourad HARMIM <mou...@li...> wrote: > Hello everyone, > I hope this message finds you well. > > My name is Mourad Harmim, a Data Engineer consultant from France. > Still getting used to GeoTools, I’m facing an issue when I try to > transform coordinates from *Lambert 2 extended (EPSG :27572) to Lambert > 93 (EPSE :2154).* > > Here is my current situation : > > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > false)* there is an error telling that Bursa Wolf parameters are > missing > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > true)* I get coordinates but they seem inaccurate (I guess it is about > a missing grid shift) > - When I use intermediate system : *Lambert 2 extended (EPSG :27572) > to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154)* I get better results > but still inaccurate. > > > I would like to know what it is the correct approch to have an accurate > transformation between these two systems. > > I hope that it is not inappropriate to ask for your help through this > email and I hope to hear from you soon. > Thank you. > Mourad Harmim. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ian Turton |
From: Mourad H. <mou...@li...> - 2024-07-31 13:30:52
|
Hello everyone, Unfortunately I could not find any clues in the public resources. Should I try a specifc version of GeoTools java dependency ? Any suggestion is warmly welcomed. Thank you, Mourad Harmim. ________________________________ De : Mourad HARMIM <mou...@li...> Envoyé : lundi 15 juillet 2024 09:52 À : Jody Garnett <jod...@gm...> Objet : RE: [Geotools-devel] Help with GeoTools : Trouble transforming coordinates Hello Jody, Thank you for your early reply. I actually added the dependency gt-epsg-hsql where the thecoordinate references are supposed to be. I also tried passing wkt definitions (which reliability are not sure) but still not working. I'll lookup the guide you provided. Let's keep in touch. Best regards, Mourad Harmim. ________________________________ De : Jody Garnett <jod...@gm...> Envoyé : lundi 15 juillet 2024 03:08 À : Mourad HARMIM <mou...@li...> Cc : geo...@li... <geo...@li...>; geo...@li... <geo...@li...> Objet : Re: [Geotools-devel] Help with GeoTools : Trouble transforming coordinates The user list is the right place to ask. I do not work on the coordinate reference system so much myself, there is a handy guide for configuring here: https://docs.geoserver.org/main/en/user/configuration/crshandling/index.html Using this approach you can provide the transform, however I am curious why GeoTools does not have the required information. Are you using gt-epsg-shall for definitions or the wkt one? If you look up online can you compare the information to what is included in GeoTools? -- Jody Garnett On Sun, Jul 14, 2024 at 5:31 PM Mourad HARMIM <mou...@li...<mailto:mou...@li...>> wrote: Hello everyone, I hope this message finds you well. My name is Mourad Harmim, a Data Engineer consultant from France. Still getting used to GeoTools, I’m facing an issue when I try to transform coordinates from Lambert 2 extended (EPSG :27572) to Lambert 93 (EPSE :2154). Here is my current situation : * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), false) there is an error telling that Bursa Wolf parameters are missing * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), true) I get coordinates but they seem inaccurate (I guess it is about a missing grid shift) * When I use intermediate system : Lambert 2 extended (EPSG :27572) to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154) I get better results but still inaccurate. I would like to know what it is the correct approch to have an accurate transformation between these two systems. I hope that it is not inappropriate to ask for your help through this email and I hope to hear from you soon. Thank you. Mourad Harmim. _______________________________________________ GeoTools-Devel mailing list Geo...@li...<mailto:Geo...@li...> https://lists.sourceforge.net/lists/listinfo/geotools-devel |
From: Ian T. <ijt...@gm...> - 2024-07-27 08:48:15
|
That all sounds like the response I would expect - GetFeatureInfo (effectively) draws the map image and returns the pixel value at the query point. So if there is no map then you get no response, if it is blank then you get 0 and if there is an image you get that value. Ian On Fri, 26 Jul 2024 at 19:46, Andrew Orzechowski < and...@gm...> wrote: > > We are using an ImageMosaic data store as part of a GeoServer 2.25.3 > deployment. The data store consists of grey scale images with applicable > time ranges. The layer that is fed by the ImageMosaic data store has the > time dimension enabled. Our users view the layers through the output of WMS > GetMap calls and they can also obtain the value at a specific point using > the GetFeatureInfo call. > > We are trying to understand the results we receive from GetFeatureInfo > when using the time range filters. > > If the user makes a GetFeatureInfo call to a location where an image > exists and the time range in the query overlaps with the image's applicable > time range, they get the value we expect. > > If the user makes a GetFeatureInfo call to a location where no image > exists regardless of the time range in the query, they get the value of 0 > back. We believe this is the result of the creation of the blank response > in the RasterLayerResponse class. > > However, if a user makes a GetFeatureInfo call to a location where an > image exists, but the time range in the query does not overlap with the > image's applicable time range, they get a response with no results. We > believe this is due to the null returned they dry run visitor logic in > RasterLayerResponse. > > Is the 0 result (due to no results ever) and empty result (no results > based on the filters) the expected behavior of GetFeatureInfo? > > Thanks, > Andy > > > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > -- Ian Turton |
From: Andrew O. <and...@gm...> - 2024-07-26 18:45:01
|
We are using an ImageMosaic data store as part of a GeoServer 2.25.3 deployment. The data store consists of grey scale images with applicable time ranges. The layer that is fed by the ImageMosaic data store has the time dimension enabled. Our users view the layers through the output of WMS GetMap calls and they can also obtain the value at a specific point using the GetFeatureInfo call. We are trying to understand the results we receive from GetFeatureInfo when using the time range filters. If the user makes a GetFeatureInfo call to a location where an image exists and the time range in the query overlaps with the image's applicable time range, they get the value we expect. If the user makes a GetFeatureInfo call to a location where no image exists regardless of the time range in the query, they get the value of 0 back. We believe this is the result of the creation of the blank response in the RasterLayerResponse class. However, if a user makes a GetFeatureInfo call to a location where an image exists, but the time range in the query does not overlap with the image's applicable time range, they get a response with no results. We believe this is due to the null returned they dry run visitor logic in RasterLayerResponse. Is the 0 result (due to no results ever) and empty result (no results based on the filters) the expected behavior of GetFeatureInfo? Thanks, Andy |
From: Jody G. <jod...@gm...> - 2024-07-15 18:04:50
|
Remember to communicate via geotools-gt2-users list so others can help out. While I responded quickly with docs I do not generally work on the referencing system. If you are unable to communicate in public there are a number of commercial support options available (including my employer). Enjoy using GoeTools! -- Jody Garnett On Jul 15, 2024 at 12:52:50 AM, Mourad HARMIM <mou...@li...> wrote: > Hello Jody, > > Thank you for your early reply. > I actually added the dependency gt-epsg-hsql where the thecoordinate > references are supposed to be. > I also tried passing wkt definitions (which reliability are not sure) but > still not working. > > I'll lookup the guide you provided. Let's keep in touch. > > Best regards, > Mourad Harmim. > ------------------------------ > *De :* Jody Garnett <jod...@gm...> > *Envoyé :* lundi 15 juillet 2024 03:08 > *À :* Mourad HARMIM <mou...@li...> > *Cc :* geo...@li... < > geo...@li...>; > geo...@li... < > geo...@li...> > *Objet :* Re: [Geotools-devel] Help with GeoTools : Trouble transforming > coordinates > > The user list is the right place to ask. > > I do not work on the coordinate reference system so much myself, there is > a handy guide for configuring here: > > https://docs.geoserver.org/main/en/user/configuration/crshandling/index.html > > Using this approach you can provide the transform, however I am curious > why GeoTools does not have the required information. Are you using > gt-epsg-shall for definitions or the wkt one? > > If you look up online can you compare the information to what is included > in GeoTools? > -- > Jody Garnett > > > On Sun, Jul 14, 2024 at 5:31 PM Mourad HARMIM <mou...@li...> > wrote: > > Hello everyone, > I hope this message finds you well. > > My name is Mourad Harmim, a Data Engineer consultant from France. > Still getting used to GeoTools, I’m facing an issue when I try to > transform coordinates from *Lambert 2 extended (EPSG :27572) to Lambert > 93 (EPSE :2154).* > > Here is my current situation : > > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > false)* there is an error telling that Bursa Wolf parameters are > missing > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > true)* I get coordinates but they seem inaccurate (I guess it is about > a missing grid shift) > - When I use intermediate system : * Lambert 2 extended (EPSG :27572) > to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154)* I get better results > but still inaccurate. > > > I would like to know what it is the correct approch to have an accurate > transformation between these two systems. > > I hope that it is not inappropriate to ask for your help through this > email and I hope to hear from you soon. > Thank you. > > Mourad Harmim. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > |
From: Jody G. <jod...@gm...> - 2024-07-15 01:09:13
|
The user list is the right place to ask. I do not work on the coordinate reference system so much myself, there is a handy guide for configuring here: https://docs.geoserver.org/main/en/user/configuration/crshandling/index.html Using this approach you can provide the transform, however I am curious why GeoTools does not have the required information. Are you using gt-epsg-shall for definitions or the wkt one? If you look up online can you compare the information to what is included in GeoTools? -- Jody Garnett On Sun, Jul 14, 2024 at 5:31 PM Mourad HARMIM <mou...@li...> wrote: > Hello everyone, > I hope this message finds you well. > > My name is Mourad Harmim, a Data Engineer consultant from France. > Still getting used to GeoTools, I’m facing an issue when I try to > transform coordinates from *Lambert 2 extended (EPSG :27572) to Lambert > 93 (EPSE :2154).* > > Here is my current situation : > > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > false)* there is an error telling that Bursa Wolf parameters are > missing > - When I use : *this.mathTransform = > CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), > true)* I get coordinates but they seem inaccurate (I guess it is about > a missing grid shift) > - When I use intermediate system : *Lambert 2 extended (EPSG :27572) > to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154)* I get better results > but still inaccurate. > > > I would like to know what it is the correct approch to have an accurate > transformation between these two systems. > > I hope that it is not inappropriate to ask for your help through this > email and I hope to hear from you soon. > Thank you. > > Mourad Harmim. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Mourad H. <mou...@li...> - 2024-07-15 00:30:40
|
Hello everyone, I hope this message finds you well. My name is Mourad Harmim, a Data Engineer consultant from France. Still getting used to GeoTools, I’m facing an issue when I try to transform coordinates from Lambert 2 extended (EPSG :27572) to Lambert 93 (EPSE :2154). Here is my current situation : * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), false) there is an error telling that Bursa Wolf parameters are missing * When I use : this.mathTransform = CRS.findMathTransform(CRS.decode("EPSG:27572") , CRS.decode("EPSG:2154"), true) I get coordinates but they seem inaccurate (I guess it is about a missing grid shift) * When I use intermediate system : Lambert 2 extended (EPSG :27572) to WSG84 (EPSG:4326) to Lambert 93 (EPSE :2154) I get better results but still inaccurate. I would like to know what it is the correct approch to have an accurate transformation between these two systems. I hope that it is not inappropriate to ask for your help through this email and I hope to hear from you soon. Thank you. Mourad Harmim. |
From: Jody G. <jod...@gm...> - 2024-07-02 04:27:03
|
The advisory for CVE-2024-36404 <https://github.com/geotools/geotools/security/advisories/GHSA-w3pj-wh35-fq8w> is now published. GeoTools 31.4 stable, GeoTools 30.4 maintenance, and GeoTools 29.6 (end of life) have been patched. I am not going to go over the details in email, please read the above link (use of CVE system avoids risk of duplicated or outdated information). Thanks to Steve for resolving this issue, and to Andrea for providing patches for select prior releases. -- Jody Garnett On Jun 18, 2024 at 4:15:27 PM, Jody Garnett <jod...@gm...> wrote: > GeoTools 31.2 is now available from source forge and maven. > > This release is provided as an urgent update to address CVE-2024-36404. We > will share details at the end of the month so you have some time to update > your projects first. > > For more information and release notes see our blog post announcement GeoTools > 31.2 Released > <http://geotoolsnews.blogspot.com/2024/06/geotools-312-released.html>. > > Thanks to Jody (and GeoCat) for making this unscheduled release. > -- > GeoTools Project Management Committee > |
From: Alexander J. - c. t. G. <a.j...@co...> - 2024-06-20 12:11:06
|
On StackOverflow there is at least one additional person who would be happy to have WKT2 support in GeoTools: https://stackoverflow.com/questions/76258547/supporting-wkt-projcrs As far as I can see the alternative for that person is to use an additional library to get WKT2 support. The person tries to avoid this and hopes that it would be included in one of the upcoming releases. We are in a similar situation. Our middleware product sits between Esri's ArcGIS server and REST requests from the user side. Given that Esri recently added WKT2 support to ArcGIS server, we expect an increased usage of the new WKT version in the future. https://developers.arcgis.com/rest/services-reference/enterprise/whats-new/#112 https://developers.arcgis.com/rest/services-reference/enterprise/create-replica/#new-at-112 I understand that the support of the new WTK version is easier said than done. I just want to create awareness that the usage of WTK2 will increase in the future and that the support of this new standard will improve the interoperability. |
From: Andrea A. <and...@ge...> - 2024-06-20 08:24:44
|
Hi Alexander, I don't think there is anything in the pipe for the short term. If you have an interest in getting it integrated, please see this guide (written for GeoServer, but valid for GeoTools as well): https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-fixes,-improvements-and-new-features-in-GeoServer Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail On Wed, Jun 19, 2024 at 10:56 PM Alexander Janzen - con terra GmbH via GeoTools-GT2-Users <geo...@li...> wrote: > Dear all, > > We have been using GeoTools for many years and expect to get soon a > requirement from the user side to support WKT2 strings. > In my research for the current state of the WKT2 support in GeoTools I > tried to parse an example WTK2 string like this: > > import org.geotools.referencing.CRS; > // ... > // please note the additional "R" as an indicator for WKT2 below > String wkt = "PROJCRS[..."; > CRS.parseWKT(wkt); > > I got the following error: Type "PROJCRS" is unknow in this context. > > Afterwards I looked in the source code and found out, that > Parser.CoordinateReferenceSystem() supports the following root nodes: > PROJCS, GEOGCS, GEOCCS, VERT_CS, LOCAL_CS, COMPD_CS, FITTED_CS. > Since any WKT2 root node is missing I assume that WKT2 support is not > implemented yet. > Then I looked in the Jira board, StackOverflow, developer and user mailing > list on that topic, but couldn't find any hints that WKT2 support is planed > for the future releases. > Since I could not find a roadmap for GeoTools too I was wondering if it is > considered to support it in the future. > > best regards, > Alexander > > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Kurt S. <sc...@gm...> - 2024-06-20 02:11:50
|
Some starter links on WKT2: https://gdal.org/development/rfc/rfc73_proj6_wkt2_srsbarn.html https://docs.ogc.org/is/12-063r5/12-063r5.html https://proj4.org/en/9.4/development/reference/cpp/cpp_general.html#standards On Wed, Jun 19, 2024 at 2:34 PM Jody Garnett <jod...@gm...> wrote: > You are the first to express interest in this, what can you tell me about > WKT2? This is the first I have personally heard of it... > -- > Jody Garnett > > > On Jun 19, 2024 at 8:08:32 AM, Alexander Janzen - con terra GmbH via > GeoTools-GT2-Users <geo...@li...> wrote: > >> Dear all, >> >> We have been using GeoTools for many years and expect to get soon a >> requirement from the user side to support WKT2 strings. >> In my research for the current state of the WKT2 support in GeoTools I >> tried to parse an example WTK2 string like this: >> >> import org.geotools.referencing.CRS; >> // ... >> // please note the additional "R" as an indicator for WKT2 below >> String wkt = "PROJCRS[..."; >> CRS.parseWKT(wkt); >> >> I got the following error: Type "PROJCRS" is unknow in this context. >> >> Afterwards I looked in the source code and found out, that >> Parser.CoordinateReferenceSystem() supports the following root nodes: >> PROJCS, GEOGCS, GEOCCS, VERT_CS, LOCAL_CS, COMPD_CS, FITTED_CS. >> Since any WKT2 root node is missing I assume that WKT2 support is not >> implemented yet. >> Then I looked in the Jira board, StackOverflow, developer and user >> mailing list on that topic, but couldn't find any hints that WKT2 support >> is planed for the future releases. >> Since I could not find a roadmap for GeoTools too I was wondering if it >> is considered to support it in the future. >> >> best regards, >> Alexander >> >> _______________________________________________ >> GeoTools-GT2-Users mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users >> > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Jody G. <jod...@gm...> - 2024-06-19 21:32:28
|
You are the first to express interest in this, what can you tell me about WKT2? This is the first I have personally heard of it... -- Jody Garnett On Jun 19, 2024 at 8:08:32 AM, Alexander Janzen - con terra GmbH via GeoTools-GT2-Users <geo...@li...> wrote: > Dear all, > > We have been using GeoTools for many years and expect to get soon a > requirement from the user side to support WKT2 strings. > In my research for the current state of the WKT2 support in GeoTools I > tried to parse an example WTK2 string like this: > > import org.geotools.referencing.CRS; > // ... > // please note the additional "R" as an indicator for WKT2 below > String wkt = "PROJCRS[..."; > CRS.parseWKT(wkt); > > I got the following error: Type "PROJCRS" is unknow in this context. > > Afterwards I looked in the source code and found out, that > Parser.CoordinateReferenceSystem() supports the following root nodes: > PROJCS, GEOGCS, GEOCCS, VERT_CS, LOCAL_CS, COMPD_CS, FITTED_CS. > Since any WKT2 root node is missing I assume that WKT2 support is not > implemented yet. > Then I looked in the Jira board, StackOverflow, developer and user mailing > list on that topic, but couldn't find any hints that WKT2 support is planed > for the future releases. > Since I could not find a roadmap for GeoTools too I was wondering if it is > considered to support it in the future. > > best regards, > Alexander > > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Alexander J. - c. t. G. <a.j...@co...> - 2024-06-19 20:55:03
|
Dear all, We have been using GeoTools for many years and expect to get soon a requirement from the user side to support WKT2 strings. In my research for the current state of the WKT2 support in GeoTools I tried to parse an example WTK2 string like this: import org.geotools.referencing.CRS; // ... // please note the additional "R" as an indicator for WKT2 below String wkt = "PROJCRS[..."; CRS.parseWKT(wkt); I got the following error: Type "PROJCRS" is unknow in this context. Afterwards I looked in the source code and found out, that Parser.CoordinateReferenceSystem() supports the following root nodes: PROJCS, GEOGCS, GEOCCS, VERT_CS, LOCAL_CS, COMPD_CS, FITTED_CS. Since any WKT2 root node is missing I assume that WKT2 support is not implemented yet. Then I looked in the Jira board, StackOverflow, developer and user mailing list on that topic, but couldn't find any hints that WKT2 support is planed for the future releases. Since I could not find a roadmap for GeoTools too I was wondering if it is considered to support it in the future. best regards, Alexander |
From: Jody G. <jod...@gm...> - 2024-06-18 23:17:16
|
GeoTools 29.6 is now available. This release is provided as an urgent update to address CVE-2024-36404. We will share details at the end of the month so you have some time to update your projects first. For more information and release notes see our blog post announcement GeoTools 29.6 Released <http://geotoolsnews.blogspot.com/2024/06/geotools-296-released.html>. Thanks to Jody (and GeoCat) for making this unscheduled release. -- GeoTools Project Management Committee |
From: Jody G. <jod...@gm...> - 2024-06-18 23:15:42
|
GeoTools 31.2 is now available from source forge and maven. This release is provided as an urgent update to address CVE-2024-36404. We will share details at the end of the month so you have some time to update your projects first. For more information and release notes see our blog post announcement GeoTools 31.2 Released <http://geotoolsnews.blogspot.com/2024/06/geotools-312-released.html>. Thanks to Jody (and GeoCat) for making this unscheduled release. -- GeoTools Project Management Committee |
From: Phil S. <P.S...@gn...> - 2024-05-16 21:09:26
|
Thanks Ian, (and Jody too). That does fill some blanks – I will give it a try. I see why you are using a writer instead of a simple toString(). As to whether ESRI agree about what geoJSON is? Well the ESRI class is called OGCGeometry, so there is hope… From: Ian Turton <ijt...@gm...> Sent: Thursday, May 16, 2024 9:02 PM To: Phil Scadden <P.S...@gn...> Cc: geo...@li... Subject: Re: [Geotools-gt2-users] getting from geometry in SimpleFeature to ESRI geometry CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe: That's probably my fault :-) GeoJSON parsing has moved to gt-geojson-core which along with the gt-geojson-store replaces the functionality in gt-geojson. The plan is at some point in the future to remove gt-geoson but currently GeoServer makes use of it (at least I think that was the problem) and I ran out of time and energy, With gt-geoson-core you should be able to do something like this: GeometryFactory gf = new GeometryFactory(); SimpleFeatureType type = DataUtilities.createType("test", "the_geom:Point:srid=4326"); SimpleFeatureBuilder builder = new SimpleFeatureBuilder(type); builder.add(gf.createPoint(new Coordinate(1.23456789, 0.123456789))); SimpleFeature feature = builder.buildFeature(null); ByteArrayOutputStream out = new ByteArrayOutputStream(); GeoJSONWriter writer = new GeoJSONWriter(out); writer.setMaxDecimals(6); writer.write(feature); Ian On Thu, 16 May 2024 at 05:56, Phil Scadden <P.S...@gn...<mailto:P.S...@gn...>> wrote: Ultimately, what I am trying to do is read some features from a geopkg using geotools, fidding with contents of the feature and then writing the Feature to an ESRI FeatureServer using the REST API. Along the way, I have to get the geotools geometry converted to an ESRI Geometry class. The ESRI OGCGeometry (https://esri.github.io/geometry-api-java<https://esri.github.io/geometry-api-java%20can> can convert to ESRI geometry, but the fromGeoJson seems to be only method for creating a OGCGeometry. What I am struggling with is getting a GeoJSON string out of geotools. I added gt-geojson module but can only see method for writing to file. Am I missing something blindingly obvious here? The documentation doesn’t seem up to date – pointing to methods that (eg GeoJSONWriter) that don’t exist (and pages 404 in the Javadoc). Using 31.0 Also looking at option of using a WKT route instead. ________________________________________________ Ngā mihi, Nā Phil Scadden (he/him) Te Raraunga me te Tātaritanga Mokowā Aronuku (Geospatial Data and Analysis) GNS Science Te Pῡ Ao 13A Alma St, Renwick, 7204 New Zealand Ph +64 27 3463185 “Whāia te iti kahurangi ki te tūohu koe me he maunga teitei” Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents. _______________________________________________ GeoTools-GT2-Users mailing list Geo...@li...<mailto:Geo...@li...> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users -- Ian Turton Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents. |
From: Ian T. <ijt...@gm...> - 2024-05-16 09:02:53
|
That's probably my fault :-) GeoJSON parsing has moved to gt-geojson-core which along with the gt-geojson-store replaces the functionality in gt-geojson. The plan is at some point in the future to remove gt-geoson but currently GeoServer makes use of it (at least I think that was the problem) and I ran out of time and energy, With gt-geoson-core you should be able to do something like this: GeometryFactory gf = new GeometryFactory(); SimpleFeatureType type = DataUtilities.createType("test", "the_geom:Point:srid=4326"); SimpleFeatureBuilder builder = new SimpleFeatureBuilder(type); builder.add(gf.createPoint(new Coordinate(1.23456789, 0.123456789))); SimpleFeature feature = builder.buildFeature(null); ByteArrayOutputStream out = new ByteArrayOutputStream(); GeoJSONWriter writer = new GeoJSONWriter(out); writer.setMaxDecimals(6); writer.write(feature); Ian On Thu, 16 May 2024 at 05:56, Phil Scadden <P.S...@gn...> wrote: > Ultimately, what I am trying to do is read some features from a geopkg > using geotools, fidding with contents of the feature and then writing the > Feature to an ESRI FeatureServer using the REST API. Along the way, I have > to get the geotools geometry converted to an ESRI Geometry class. > > The ESRI OGCGeometry (https://esri.github.io/geometry-api-java > <https://esri.github.io/geometry-api-java%20can> can convert to ESRI > geometry, but the fromGeoJson seems to be only method for creating a > OGCGeometry. > > > > What I am struggling with is getting a GeoJSON string out of geotools. I > added gt-geojson module but can only see method for writing to file. Am I > missing something blindingly obvious here? The documentation doesn’t seem > up to date – pointing to methods that (eg GeoJSONWriter) that don’t exist > (and pages 404 in the Javadoc). > > > > Using 31.0 > > > > Also looking at option of using a WKT route instead. > > > > > > ________________________________________________ > > Ngā mihi, Nā Phil Scadden (he/him) > > Te Raraunga me te Tātaritanga Mokowā Aronuku (Geospatial Data and > Analysis) > > *GNS Science* *Te Pῡ Ao* > > 13A Alma St, Renwick, 7204 > > New Zealand Ph +64 27 3463185 > > > > “Whāia te iti kahurangi ki te tūohu koe me he maunga teitei” > > > Notice: This email and any attachments are confidential and may not be > used, published or redistributed without the prior written consent of the > Institute of Geological and Nuclear Sciences Limited (GNS Science). If > received in error please destroy and immediately notify GNS Science. Do not > copy or disclose the contents. > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > -- Ian Turton |
From: Jody G. <jod...@gm...> - 2024-05-16 07:41:36
|
Are we sure GeoTools and ESRI geometry-api have the same GeoJSON in mind? I would look at *test cases* for the GeoTools functionality. Where possible I always try and get the docs to include example code directly from test cases (so it is not out of date). The geojson module is unsupported, so while it compiles it may not run? Kind of surprising this has not been popular enough to be completed 🙂 There isa specific GeometryJSONTest <https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/test/java/org/geotools/geojson/GeometryJSONTest.java> that appears to have examples of using Geometry in isolation (not writing to a file). -- Jody Garnett On May 15, 2024 at 9:39:27 PM, Phil Scadden <P.S...@gn...> wrote: > Ultimately, what I am trying to do is read some features from a geopkg > using geotools, fidding with contents of the feature and then writing the > Feature to an ESRI FeatureServer using the REST API. Along the way, I have > to get the geotools geometry converted to an ESRI Geometry class. > > The ESRI OGCGeometry (https://esri.github.io/geometry-api-java > <https://esri.github.io/geometry-api-java%20can> can convert to ESRI > geometry, but the fromGeoJson seems to be only method for creating a > OGCGeometry. > > > > What I am struggling with is getting a GeoJSON string out of geotools. I > added gt-geojson module but can only see method for writing to file. Am I > missing something blindingly obvious here? The documentation doesn’t seem > up to date – pointing to methods that (eg GeoJSONWriter) that don’t exist > (and pages 404 in the Javadoc). > > > > Using 31.0 > > > > Also looking at option of using a WKT route instead. > > > > > > ________________________________________________ > > Ngā mihi, Nā Phil Scadden (he/him) > > Te Raraunga me te Tātaritanga Mokowā Aronuku (Geospatial Data and > Analysis) > > *GNS Science* *Te Pῡ Ao* > > 13A Alma St, Renwick, 7204 > > New Zealand Ph +64 27 3463185 > > > > “Whāia te iti kahurangi ki te tūohu koe me he maunga teitei” > > > Notice: This email and any attachments are confidential and may not be > used, published or redistributed without the prior written consent of the > Institute of Geological and Nuclear Sciences Limited (GNS Science). If > received in error please destroy and immediately notify GNS Science. Do not > copy or disclose the contents. > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Phil S. <P.S...@gn...> - 2024-05-16 04:55:01
|
Ultimately, what I am trying to do is read some features from a geopkg using geotools, fidding with contents of the feature and then writing the Feature to an ESRI FeatureServer using the REST API. Along the way, I have to get the geotools geometry converted to an ESRI Geometry class. The ESRI OGCGeometry (https://esri.github.io/geometry-api-java<https://esri.github.io/geometry-api-java%20can> can convert to ESRI geometry, but the fromGeoJson seems to be only method for creating a OGCGeometry. What I am struggling with is getting a GeoJSON string out of geotools. I added gt-geojson module but can only see method for writing to file. Am I missing something blindingly obvious here? The documentation doesn’t seem up to date – pointing to methods that (eg GeoJSONWriter) that don’t exist (and pages 404 in the Javadoc). Using 31.0 Also looking at option of using a WKT route instead. ________________________________________________ Ngā mihi, Nā Phil Scadden (he/him) Te Raraunga me te Tātaritanga Mokowā Aronuku (Geospatial Data and Analysis) GNS Science Te Pῡ Ao 13A Alma St, Renwick, 7204 New Zealand Ph +64 27 3463185 “Whāia te iti kahurangi ki te tūohu koe me he maunga teitei” Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents. |
From: Jason T. <kat...@gm...> - 2024-05-14 14:18:07
|
You could try examining your dependency tree - https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html i.e. you can run something like: gradle dependencies This should tell you if the unit-api is included, or if multiple conflicting versions are included, which could also cause problems. -Jason On Tue, May 14, 2024, 5:41 AM Ian Turton <ijt...@gm...> wrote: > I don't know how gradle works but looking at `mvn dependency:tree` gives > me the following > > [INFO] org.geotools:gt-api:jar:32-SNAPSHOT > [INFO] +- commons-pool:commons-pool:jar:1.5.4:compile > [INFO] +- systems.uom:systems-common:jar:2.1:compile > [INFO] | +- javax.measure:unit-api:jar:2.1.3:compile > [INFO] | +- si.uom:si-quantity:jar:2.1:compile > [INFO] | \- si.uom:si-units:jar:2.1:compile > [INFO] | \- jakarta.annotation:jakarta.annotation-api:jar:1.3.4:compile > [INFO] +- tech.units:indriya:jar:2.1.3:compile > [INFO] | +- tech.uom.lib:uom-lib-common:jar:2.1:compile > [INFO] | +- javax.inject:javax.inject:jar:1:compile > [INFO] | \- org.apiguardian:apiguardian-api:jar:1.1.1:compile > [INFO] +- org.locationtech.jts:jts-core:jar:1.19.0:compile > [INFO] +- javax.media:jai_codec:jar:1.1.3:test > [INFO] +- javax.media:jai_core:jar:1.1.3:compile > [INFO] \- junit:junit:jar:4.13.1:test > [INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test > > So it should be pulled in via gt-api > > Ian > > On Tue, 14 May 2024 at 10:18, Sara Schade <s.s...@su...> > wrote: > >> Hi all, >> >> is there a known solution to integrate GeoTools correctly in a Gradle >> project? At the moment we are going from one dependency error during run to >> the next. At the moment we are stuck here: >> >> Caused by: java.lang.ClassNotFoundException: javax.measure.Unit >> >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) >> >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) >> >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) >> >> We have a composite build >> and our dependencies are: >> >> implementation 'org.geotools:gt-main:30.2' >> >> implementation 'org.geotools:gt-referencing:30.2' >> >> implementation 'org.geotools:gt-epsg-wkt:30.2' >> >> implementation 'org.geotools:gt-api:30.2' >> >> api 'org.locationtech.jts:jts-core:1.19.0' >> >> implementation 'org.geotools:gt-epsg-hsql:30.2' >> >> implementation 'org.geotools:gt-epsg-extension:30.2' >> >> implementation 'org.geotools:gt-metadata:30.2' >> >> implementation 'javax.media:jai_core:1.1.3' >> >> implementation 'org.geotools:gt-coverage:30.2' >> >> implementation 'org.geotools:gt-coverage-api:30.2' >> >> implementation 'org.geotools:gt-geotiff:30.2' >> >> implementation 'org.geotools:gt-shapefile:30.2' >> thank you. >> Best regards Sara >> >> -- >> ------------------------ >> Sara Schade >> Dipl.-Geol., Senior Scientist >> INSIGHT >> Geologische Softwaresysteme GmbH >> Tel.: 0176-21428186 >> ------------------------ >> >> _______________________________________________ >> GeoTools-GT2-Users mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users >> > > > -- > Ian Turton > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > |
From: Ian T. <ijt...@gm...> - 2024-05-14 09:40:41
|
I don't know how gradle works but looking at `mvn dependency:tree` gives me the following [INFO] org.geotools:gt-api:jar:32-SNAPSHOT [INFO] +- commons-pool:commons-pool:jar:1.5.4:compile [INFO] +- systems.uom:systems-common:jar:2.1:compile [INFO] | +- javax.measure:unit-api:jar:2.1.3:compile [INFO] | +- si.uom:si-quantity:jar:2.1:compile [INFO] | \- si.uom:si-units:jar:2.1:compile [INFO] | \- jakarta.annotation:jakarta.annotation-api:jar:1.3.4:compile [INFO] +- tech.units:indriya:jar:2.1.3:compile [INFO] | +- tech.uom.lib:uom-lib-common:jar:2.1:compile [INFO] | +- javax.inject:javax.inject:jar:1:compile [INFO] | \- org.apiguardian:apiguardian-api:jar:1.1.1:compile [INFO] +- org.locationtech.jts:jts-core:jar:1.19.0:compile [INFO] +- javax.media:jai_codec:jar:1.1.3:test [INFO] +- javax.media:jai_core:jar:1.1.3:compile [INFO] \- junit:junit:jar:4.13.1:test [INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test So it should be pulled in via gt-api Ian On Tue, 14 May 2024 at 10:18, Sara Schade <s.s...@su...> wrote: > Hi all, > > is there a known solution to integrate GeoTools correctly in a Gradle > project? At the moment we are going from one dependency error during run to > the next. At the moment we are stuck here: > > Caused by: java.lang.ClassNotFoundException: javax.measure.Unit > > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) > > at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) > > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) > > We have a composite build > and our dependencies are: > > implementation 'org.geotools:gt-main:30.2' > > implementation 'org.geotools:gt-referencing:30.2' > > implementation 'org.geotools:gt-epsg-wkt:30.2' > > implementation 'org.geotools:gt-api:30.2' > > api 'org.locationtech.jts:jts-core:1.19.0' > > implementation 'org.geotools:gt-epsg-hsql:30.2' > > implementation 'org.geotools:gt-epsg-extension:30.2' > > implementation 'org.geotools:gt-metadata:30.2' > > implementation 'javax.media:jai_core:1.1.3' > > implementation 'org.geotools:gt-coverage:30.2' > > implementation 'org.geotools:gt-coverage-api:30.2' > > implementation 'org.geotools:gt-geotiff:30.2' > > implementation 'org.geotools:gt-shapefile:30.2' > thank you. > Best regards Sara > > -- > ------------------------ > Sara Schade > Dipl.-Geol., Senior Scientist > INSIGHT > Geologische Softwaresysteme GmbH > Tel.: 0176-21428186 > ------------------------ > > _______________________________________________ > GeoTools-GT2-Users mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > -- Ian Turton |