Re: [Geotools-devel] GeoTools / GeoServer PMC meeting - 2024-01-02

[Brad Hards]

On Wednesday, 3 January 2024 5:35:42 AM AEDT Torben Barsballe wrote:
> Wicket 9 upgrade
> 
> https://github.com/geoserver/geoserver/pull/7154
> 
> Need to collect all pages and panels that need to be tested, make a list,
> and divide the list amongst participants to the testing effort. First we
> need Brad’s ok to move on.

Part of the Wicket 9 changes is a (strict) Content Security Policy.
See
https://nightlies.apache.org/wicket/guide/9.x/single.html#_content_security_policy_csp

CSP could help us a lot with security. See
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
for what it does. The TL;DR; version is it blocks most XSS attacks.

It doesn't come for free though. We need to move or remove all the
inline styling and javascript. For inline javascript, it
needs to go into a "renderHead()" method.

We also need to remove inline event handlers.

I would like help to do that work, although I will get some of it done soon.
Please let me know if you can help

Since this stands a pretty good chance of breaking stuff,
we should defer the manual testing.

The only good news I have is that it looks like there will be automation
support for getting from Wicket 9 to Wicket 10.
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-AddmigrationrecipestoWicket10WICKET-7029

Brad




___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposed MF-JSON unsupported module

[Brad Hards]

As flagged in gitter, I am (virtually) attending the OGC Vector API code 
sprint. There is interest in an OGC Moving Features JSON implementation for 
GeoTools.  Moving Features is (simplistically) like OGC Simple Features with a 
time attribute, except the time attribute is really a temporal geometry.

There are two encodings, as described in https://docs.opengeospatial.org/is/
19-045r3/19-045r3.html#_overview_of_moving_features_json_encodings_informative

The goal (possibly not within this sprint) is to support both as a Store.

I request approval to create a new unsupported module for this work, under
geotools/modules/unsupported/mfjson

Brad






___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Patch for ticket number GEOT-4849

[Brad Hards]

Thanks for your interest in GeoTools.

 

Procedures for contributing are given in 
https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md

 

That will point you off to 
http://docs.geotools.org/latest/developer/procedures/contribute.html which 
provides more detail on how to proceed.

 

Brad

 

From: Fenil Jain  
Sent: Tuesday, 16 July 2019 7:35 AM
To: geotools-devel@lists.sourceforge.net
Subject: [Geotools-devel] Patch for ticket number GEOT-4849

 

Hi,

I would like to submit a patch for the issue "AbstractCachedAuthorityFactory is 
improperly caching dissimilar objects with the same key" which is still open,

 

Issue Description: 

 

I am trying to export the CRS NAD27 / Michigan South with EPSG code 6202 from 
the latest EPSG database. While doing so I am getting the following 
ClassCastException

java.lang.ClassCastException: 
org.geotools.referencing.datum.DefaultGeodeticDatum cannot be cast to 

 

Ticket details:

https://osgeo-org.atlassian.net/browse/GEOT-4849




Thanks and Regards,

 

Fenil Jain

Software Developer

 

fenil.j...@int.com  

INT, Inc. - Empowering Visualization

Celebrate our 30th anniversary with us!

 

 


 

 

Virus-free.  

 www.avast.com 

 

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] The dark side of the backport plugin: remember to delete that branch! (and some cleanup needed)

[Brad Hards]

Most of the easy ones (including some old “revert” branches, from reverting on 
github) are removed.

 

There are a bunch of additional branches where I will put a simple message on 
the PR to flag it as requiring attention.

 

We also have some really old feature branches. I’ll flag those later too.

 

Brad

 

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] The dark side of the backport plugin: remember to delete that branch! (and some cleanup needed)

[Brad Hards]

That seems like something I could do on a tired Friday night.

 

Brad

 

From: Andrea Aime  
Sent: Friday, 12 July 2019 7:32 PM
To: Geoserver-devel ; Geotools-Devel 
list 
Subject: [Geotools-devel] The dark side of the backport plugin: remember to 
delete that branch! (and some cleanup needed)

 

Hi,

when using the backport labels and bot please always remember to delete 
backport branches after

merging the backport PRs:

 

 



 

This is kind of important because the bot opens the branches in the project 
itself, and the branches

have been accumulating, see an example from GeoServer:

 

 



 

Also, if a good soul had time to go through the existing ones, and delete them, 
that would

be nice! :-D

 

Cheers

Andrea

 

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 
for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions 
S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: 
+39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it 
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. 

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Remove broken (AbstractDataStoreFactory) modules?

[Brad Hards]

As part of the https://osgeo-org.atlassian.net/browse/GEOT-5859   upgrade
from commons httpclient to httpcomponents 4.x I've noted some broken modules
(won't build because of AbstractDataStoreFactory) that use that API, such as
couchdb and the app-schema webservice.

 

Not related to httpclient upgrade, but I also see excel and edigeo haven't
been upgraded from AbstractDataStoreFactory.

 

Have we waited long enough to remove those from master? They'd obviously
still be in git if someone wants to revive it.

 

Brad

 

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] WKT Parser Z and M support

[Brad Hards]

> Sorry if this hits the wrong email list, but I am not getting responses
from users,
> and the one response I did get pointed at a third party product. I need to
know
> if Geotools will support POINT M and POINT Z WKT values. eg. POINT Z(48.44
-
> 123.37 123)
Your response is at:
https://sourceforge.net/p/geotools/mailman/message/35966513/

Brad



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

[Brad Hards]

I'd like to emphasise that I have no strong feeling one way or the other.
It was just a "something to consider" rather than an objection to the current 
proposal.

Brad

> -Original Message-
> From: Andrea Aime [mailto:andrea.a...@geo-solutions.it]
> Sent: Monday, 5 June 2017 15:52
> To: Ben Caradoc-Davies 
> Cc: Geotools-Devel list 
> Subject: Re: [Geotools-devel] A few changes coming to the CSS module (and
> then its graduation)
>
> On Sun, Jun 4, 2017 at 10:58 PM, Ben Caradoc-Davies   > wrote:
>
>
>   Andrea,
>
>   do you mean "m" for "milli"? The SI prefix for "micro" is "µ".
>
>
>
> Yep, you're right, sorry!
> Anyhow, what do we do about that feedback?
>
> Cheers
> Andrea
>
> --
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
>
> Ing. Andrea Aime
>
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
>
> 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.
>
>
> ---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

[Brad Hards]

0530 local - please accept my apologies.

Brad




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 16:30 UTC on Tuesday

[Brad Hards]

Please accept my apologies for this meeting.

Brad




--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] jts use of Shapefile Reader

[Brad Hards]

Can the copyright really be 2003 for OSGEO when it didn't exist (with that 
name) until 2006?

Brad

> -Original Message-
> From: Jody Garnett [mailto:jody.garn...@gmail.com]
> Sent: Friday, 2 December 2016 10:47
> To: GeoTools Developers ; James
> Macgill 
> Cc: Martin Davis 
> Subject: Re: [Geotools-devel] jts use of Shapefile Reader
>
> Thanks everyone, here is a draft letter:
>
> https://github.com/geotools/geotools/wiki/JTS-Shapefile-Contribution
>
>
> I had to go and create a BSD license for us to refer to.
>
> --
> Jody Garnett
>
> On 8 November 2016 at 10:49, Jody Garnett   > wrote:
>
>
>   Got a request from working with Martin on the next JTS release:
>
>   As part of relicensing JTS we are hunting down where external
> contributions came from, one such is "ShapefileReader" from an early 
> GeoTools
> 2 release (before the switch to the file io api).
>
>   Can I ask for PSC approval to send an email/letter to Martin giving him
> permission to relicense this implementation
>  org/locationtech/jtstest/testbuilder/io/shapefile> . This is similar to how 
> we
> have donated code to GeoAPI in the past (or how we accept code from the
> GeoServer PSC).
>
>   The author in question, James Macgill, has signed a code contribution
> license so we (as a PSC) are in position donate this code to the JTS 
> project. I
> have also emailed James Macgill so he knows what we are up to :)
>   --
>   Jody Garnett
>




--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Fwd: Can/should we activate the github squash commits on merge option?

[Brad Hards]

> Oooh... does that mean we also get rid of the blasted merge commit and 
> retain
> a more linear history? :-)
Indeed it does.

https://github.com/codice/imaging-nitf/commits/master shows a couple of recent 
samples.

I note that it modifies the commit message "headline" to include a ref to the 
pull request, so you can still see where it came from.

Brad




--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Different time for next meeting?

[Brad Hards]

0130 is definitely out unless it’s a major / significant activity, where I can 
do the occasional all-night effort.

I sleep 2200 to 0600 local, sometimes more.

Brad


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5431) Add documentation for mongodb datastore

[Brad Hards (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Brad Hards created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5431  
 
 
  Add documentation for mongodb datastore   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 15.0  
 
 
Assignee: 
 Brad Hards  
 
 
Components: 
 unsupported  
 
 
Created: 
 02/Jun/16 1:22 PM  
 
 
Priority: 
  Low  
 
 
Reporter: 
 Brad Hards  
 

  
 
 
 
 

 
 It would be useful to migrate the existing mongodb datastore module readme.rst into the user manual.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] 15.0 Release blog draft

[Brad Hards]

> The GeoTools team is pleased to announce GeoTools 14-RC1:
Perhaps you wanted 15 or 15.0 here

> New features and improvements:

> • Ignore NetCDF grid_mapping_name that is present but unsupported
This is arguably a bug fix. Not that concerned though.

> • Java 8 is now required. Please view the install guide for details.
This is probably important enough to put at the top, rather than the end.
Just after the maven link, I'd add:
"This release of GeoTools requires Java 8. Please review the install guide for 
details".

Otherwise looks good.

Brad



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Java 8 migration: call for volunteers

[Brad Hards]

On Wed, 4 Nov 2015 10:24:59 AM Ben Caradoc-Davies wrote:
> GeoTools and GeoServer master are moving to Java 8, once CITE tests and
> builds are working again. This will include moving to Java 8 JDK,
> setting source+target to 1.8, cleaning up failures on Jenkins, and
> sanity testing of build artifacts.
> 
> Any volunteers to lead this process?
I don't have the experience or time to lead it, but I can say that I've been 
building both GeoTools and GeoServer on JDK8 for a while. That is usually the 
only configuration I actually test locally. 

Brad


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5279) Update WFS 1.1 schema

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5279 
 
 
 
  Update WFS 1.1 schema  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Affects Versions:
 

 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 opengis 
 
 
 

Created:
 

 02/Nov/15 11:05 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 
Update WFS 1.1.0 schema to match recent changes, as originally identified at https://osgeo-org.atlassian.net/browse/GEOS-2485 
After normalising to match current schema, it appears the change are likely to be: 

 

--- a/modules/ogc/net.opengis.wfs/schemas/wfs/1.1.0/wfs.xsd
+++ b/modules/ogc/net.opengis.wfs/schemas/wfs/1.1.0/wfs.xsd
@@ -7,7 +7,13 @@
xmlns:gml="http://www.opengis.net/gml"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
-   elementFormDefault="qualified" version="1.1.0">
+   elementFormDefault="qualified" version="1.1.2.0">
+
+   
 

[Geotools-devel] [JIRA] (GEOT-5278) Add support for new-style coordinate WKT (OGC 12-063r5)

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5278 
 
 
 
  Add support for new-style coordinate WKT (OGC 12-063r5)  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  New Feature 
 
 
 

Affects Versions:
 

 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 referencing 
 
 
 

Created:
 

 31/Oct/15 8:18 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 
GeoTools referencing wkt parser does not appear to handle the WKT format presented in OGC 12-063r5.  
Here is a junit test example that shows the problem: 

 

-- a/modules/library/referencing/src/test/java/org/geotools/referencing/wkt/ParserTest.java
+++ b/modules/library/referencing/src/test/java/org/geotools/referencing/wkt/ParserTest.java
@@ -383,4 +383,30 @@ public final class ParserTest {
 public void testAuthorityCodeParsing() throws IOException, ParseException {
 testParsing(new Parser(), "wkt/AuthorityCode.txt");
 }
+
+@Test
+public void test12_063r5() throws ParseException {
+final Parser parser = new Parser();
+
+String wkt1 =  "PROJCRS[\"ETRS89 Lambert Azimuthal Equal Area CRS\",  BASEGEODCRS[\"ETRS89\",\n" +
+" DATUM[\"ETRS89\&

Re: [Geotools-devel] Handling non-working projections / CRS

[Brad Hards]

On Thu, 1 Oct 2015 10:04:28 AM Andrea Aime wrote:
> On Thu, Oct 1, 2015 at 7:42 AM, Brad Hards <br...@frogmouth.net> wrote:
> > That does appear to work, but its way too slow - it makes the WMS module
> > build 6 times slower.
> > 
> > So I'm thinking of caching results. However I need guidance on whether the
> > supported codes can possibly change at runtime? If it can change, can it
> > change in such a way that an existing EPSG code might stop or start
> > working?
> > Or will any runtime changes only be new codes?
> 
> Not at runtime, but there is an  issue, the data dir used in tests
> is destroyed and rebuilt at every test run (for each class, not method).
I'm less concerned that tests are slow, but more concerned that 
GetCapabilities becomes slow in production.

If we create the list at startup, there still could be some way to get 
reasonable speed for subsequent calls. Maybe a singleton that has the server-
wide list (Set) of CRS codes that work.

> We could create a blacklist in the user_projections storage, that also has
> its own
> problems though, as supported EPSG codes evolve over time, and the data
> dirs are long lived.
> 
> > The other approach is to thin the list of codes that are provided by
> > GeoTools
> > to only those that will work (by a combination of removing those that can
> > never be supported by decode(), and fixing the cases that could be
> > supported). The problem is that it might still have plugged-in that are
> > not
> > supportable, and there is a gap between "never supported" and "works
> > perfectly".
> 
> Right, that is another issue, everything in the projection subsystem is
> pluggable,
> which makes it hard to setup a query that would return only what's
> supported.
> I have witnessed installations that had custom plugins with extra
> projections
> support compared to the base GeoServer, for example.
Presumably those custom plugins work though, so the blacklist (or whitelist by 
exception) would only apply to those that we "know" about. Are the custom ones 
in the EPSG namespace?
 
> > Another variation would be to have a whitelist of codes that are expected
> > to
> > work. That whitelist could be represented in GeoTools by a new function
> > (like CRS.getDecodeableCodes(String authority) or similar). That would be
> > a maintenance burden, and we'd lose support for things that might work.
> > 
> > Any suggestions?
> 
> Err... I'm not sure I have a good solution... time ago there was this
> suggestion
> to have the WMS caps only report the list of CRS that are actually in use,
> plus some well known ones (e.g., 3857).
> This could be a flag in the WMS configuration, enabled by default in the
> release
> data directory.
So the "Limited SRS list" would be the default. We could do a subset with no 
code changes, just by modifying the data dirs. 

It would need to cycle through all the layers to find out the CRS that are in 
use though.

Brad

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Handling non-working projections / CRS

[Brad Hards]

There is a very wide range of EPSG codes supported in GeoServer, based on the
underlying Geotools support.

The problem is that a few don't work. There are bug reports about this:
https://osgeo-org.atlassian.net/browse/GEOS-3935
https://osgeo-org.atlassian.net/browse/GEOS-4010
and perhaps others.

That is not spec compliant, and is causing trouble in my attempt to be able to
run CITE tests against a "standard" geoserver release data_dir, because the
CITE tests (WMS 1.1) try every SRS against every map.

So I did some experiments on filtering out the EPSG codes, with logic like:

private static boolean epsgCrsCodeIsNotSupported(String code) {
if ("EPSG:WGS84(DD)".equals(code)) {
return true;
}

try {
CoordinateReferenceSystem crs = CRS.decode(code);
if (crs.getCoordinateSystem().getDimension() != 2) {
return true;
}
} catch (NoSuchAuthorityCodeException ex) {
return true;
} catch (FactoryException ex) {
return true;
}

return false;
}
 
in the WMS GetCapabilities transformer.

(yeah, it probably would help if I reversed the sense of the tests).

The problem cases are listed at the end if anyone cares.

That does appear to work, but its way too slow - it makes the WMS module
build 6 times slower.

So I'm thinking of caching results. However I need guidance on whether the 
supported codes can possibly change at runtime? If it can change, can it
change in such a way that an existing EPSG code might stop or start working?
Or will any runtime changes only be new codes?

The other approach is to thin the list of codes that are provided by GeoTools
to only those that will work (by a combination of removing those that can
never be supported by decode(), and fixing the cases that could be
supported). The problem is that it might still have plugged-in that are not
supportable, and there is a gap between "never supported" and "works
perfectly".

Another variation would be to have a whitelist of codes that are expected to
work. That whitelist could be represented in GeoTools by a new function
(like CRS.getDecodeableCodes(String authority) or similar). That would be
a maintenance burden, and we'd lose support for things that might work.

Any suggestions?

Brad


The problems follow. EPSG:5820 is particularly strange...

EPSG code EPSG:2036 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2037 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2038 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2139 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2140 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2141 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2142 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2143 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2144 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2145 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2146 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2147 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2148 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2149 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2150 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2151 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2152 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2153 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2191 does not decode:org.opengis.referencing.FactoryException: 
Unit conversion from "DMS" to "°" is non-linear.
EPSG code EPSG:2218 does not 
decode:org.opengis.referencing.NoSuchIdentifierException: No 

[Geotools-devel] [JIRA] (GEOT-5230) GeoPackage has old gpkg_contents table default

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5230 
 
 
 
  GeoPackage has old gpkg_contents table default  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 geopkg 
 
 
 

Created:
 

 27/Sep/15 10:21 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 
GeoPackage SQL current reads 

 

last_change DATETIME NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ',CURRENT_TIMESTAMP)),
 

 
but it should be 

 

last_change DATETIME NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ','now')),
 

 
This was changed in https://github.com/opengeospatial/geopackage/commit/19edbe8d97acd40eba92fce000a4d8bbc033b63b and inconsistencies on this were one of the outcomes of the GeoPackage plugfest

[Geotools-devel] [JIRA] (GEOT-5227) GeometryBuilder setCoordianteReferenceSystem() should be setCoordinateReferenceSystem()

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5227 
 
 
 
  GeometryBuilder setCoordianteReferenceSystem() should be setCoordinateReferenceSystem()  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 referencing 
 
 
 

Created:
 

 26/Sep/15 11:17 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 
We should deprecate the old method and introduce the new one. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5228) Strange LGPL interpretation in FAQ

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5228 
 
 
 
  Strange LGPL interpretation in FAQ  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 docs 
 
 
 

Created:
 

 26/Sep/15 11:28 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 

This means you can use GeoTools as a library but you cannot incorporate GeoTools code directly into your GLP application. Legally, the latter amounts to re-licensing GeoTools under a new license and you do not have the right to do so. 
 
However the LGPL does allow this - see section 3 of http://www.gnu.org/licenses/lgpl-2.1.html which says: 

You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices

[Geotools-devel] [JIRA] (GEOT-5229) Fix documentation typos

[Brad Hards (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Brad Hards created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5229 
 
 
 
  Fix documentation typos  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Task 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 docs 
 
 
 

Created:
 

 27/Sep/15 6:34 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Brad Hards 
 
 
 
 
 
 
 
 
 
 
There are a few typos in the documentation. The docs would probably read better without them. This task is to correct some typos. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v7.0.0

[Geotools-devel] locations.csv is out-of-date

[Brad Hards]

http://docs.geotools.org/latest/userguide/_downloads/locations.csv appears to 
be missing a row.

Do we have official numbers and a representative location for 2015?

Brad


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] OGC WMTS 1.0.0 client

[Brad Hards]

On Thu, 17 Sep 2015 04:02:38 PM Christian Mueller wrote:
> Hi
> 
> I have a mandate to develop/maintain  a WMTS client. At the moment I am
> unsure where to start. WMS is an extension and I think WMTS is also a
> candidate for an extension.
Based on the WMTS implementation I did for OWSlib 
(https://github.com/geopython/OWSLib), I can say that servers aren't all that 
consistent in their implementation. Focusing on the specific target is a good 
idea.

Brad


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Testing 14.0-M1 artifacts.

[Brad Hards]

I downloaded all the artifacts off the geotools.org (which SourceForge 
redirected me to a mirror in Japan), unpacked them all successfully.

I build the project files (i.e. mvn clean install) for the following 
configurations:
 - mvn clean install
 - mvn clean install -Dall
 - mvn clean install -Dpending

All completed OK.

Brad


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Handling reference times and named elevations

[Brad Hards]

Following on from the discussion on relative times, I've come across an 
weather display that might benefit from reference_time and named elevation 
levels, vaguely like the way OGC 12-111r1 describes it.

Its pretty common to get weather data with two time dimensions:
 - the date / time that the forecast was (notionally) issued
 - a set of offsets from that date/time showing how the forecast changes

So for the last forecast might be issued at 2014-12-04T00:00:00, and there 
is data at 0, 3, 6 ... 72 hours from that forecast date/time.

You can see an example of this at:
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.003.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.006.png

http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.072.png

There will be another forecast for 2014-12-04T06:00:00, and again there is 
data at 0, 3, 6 ... 72 hours from that forecast date/time.

From reading OGC 12-111r1, it looks like this can be handled by using 
reference_time and time dimensions. If I'm reading it right, the issue 
date/time would be the reference_time dimension, and the offsets are the 
time dimension; although time would need to be converted from an hours offset 
to an ISO8601 date/time.

*Questions*:
1. Does this look like it would be worth adding to GeoTools ImageMosaic and 
GeoServer?

2. If so, should there be a special GeoTools properties extractor (or maybe 
magic properties combiner) to generate time and reference_time based on a 
forecast time and offset? Or does it make more sense to just have the raw 
values and produce the ISO8601 datetime on the GeoServer publishing side?


Conversely, elevations aren't always in numbers. Following on from the example 
above:
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/850hPa/IDY20301.windbarb-850hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/700hPa/IDY20301.windbarb-700hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/500hPa/IDY20301.windbarb-500hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/200hPa/IDY20301.windbarb-200hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/gradient/IDY20301.windbarb-gradient.000.png
(the same time intervals work for those interested).

OGC 12-111r1 calls that a named surface (with UNITS=computed_surface and no 
unit symbols. It looks like that will already work on the GeoTools ImageMosaic 
side, and you can publish a layer with this in GeoServer  but it throws an 
IllegalStateException when trying to get the layer (Unable to computer 
extrema value). 

*Question*
3. If the elevation is of type String, should we just publish it as a named 
surface? It would require some slightly different logic on GetMap (essentially 
the decision tree shown in Figure 6 of the OGC document).

4. It looks to me like the elevation part is probably a lot easier. Any 
suggestions for implementation?

5. If I do implement it, would it require GSIP? One for each of elevation and 
reference_time?

Brad

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] JDK8 - remove method from graph extension?

[Brad Hards]

Since JDK7 is potentially EOL in about 6 months 
(http://www.oracle.com/technetwork/java/eol-135779.html), I 
thought I'd look at JDK8 builds for geotools.

As it turns out, there are only two problems. One set of tests
for HTTPUtil fails because of hashing algorithm changes. Easy
to fix (assuming Jody will let me have one more TreeMap).

The other problem is with a new method added to Map.
http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-java.lang.Object-

That conflicts with the implementation (and semantics) of
an existing method provided by the MultiMap class
in the graph extension. That method appears to be unused
in geotools (well, JDK7 compiles geotools without it).

I'm a little uncomfortable with this change, because it is
public API (albeit in an extension) and I don't fully understand
how the API rules play on this.

--- 
a/modules/extension/graph/src/main/java/org/geotools/graph/util/MultiMap.java
+++ 
b/modules/extension/graph/src/main/java/org/geotools/graph/util/MultiMap.java
@@ -137,13 +137,5 @@ public class MultiMap implements Map, Serializable {
   public Object remove(Object key) {
 return(m_map.remove(key));
   }
-  
-  public Object remove(Object key, Object value) {
-Collection c = (Collection)m_map.get(key);
-c.remove(value);
-return(value);
-  }
-  
-
 
 }


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] JDK8 - remove method from graph extension?

[Brad Hards]

On Thu, 6 Nov 2014 03:20:24 PM you wrote:
 Rename MultiMap.remove(Object,Object) to something that doesn't conflict
 with with the new method on Map. At the same time ensure that the all the
 callers of the method are also updated.
I was planning to do that (maybe renaming to removeValueFromCollection), but 
there are no callers that I can find, at least in GeoTools. I subsequently 
build GeoServer against that (at least, I hope that is what maven did today). 

Brad

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4904) pom.xml has broken links

[Brad Hards (JIRA)]

Title: Message Title










 

 Brad Hards created an issue


















 GeoTools /  GEOT-4904



  pom.xml has broken links 










Issue Type:

  Bug




Affects Versions:


 12.0




Assignee:


 Unassigned




Created:


 26/Sep/14 4:55 AM




Priority:

  Trivial




Reporter:

 Brad Hards










There are broken links in the top level pom, such as the developer links and the mailing list URLs.












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c