Re: [Geotools-devel] GeoTools PMC meeting notes, May 21 2024
On Wed, May 22, 2024 at 8:12 AM Jody Garnett wrote: > >- > >For intermittent failures >- > > Quick: rerun failed test … > - > > Why: Each example needs investigation > - > > windows locked file is a common failure with older file system? > - > > Perhaps some state changed (environmental variable) that affects > another test… > - > > Perhaps opening a port → randomise the port used (minimise error) > > I've tried to reproduce and fix the existing intermittent failures but I just cannot reproduce any of them on my machine, If anyone else could give it a try, it would help. In terms of ports/disk locations, there are a couple issues, but they are happening only on the Jenkins server, where all the builds are happening on the same machine. Github actions are supposedly isolated, each one running on a separate VM, and are typically failing for other reasons... many fail to download jars from the repository, others fail for locking issues probably related to a network filesystem, others seem time related. Again, please try to locate one failure that's bothering you, and give a try reproducing it, or maybe just trying to imagine how it works and attempt a PR that may fix it. Cheers Andrea ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Individual Contributor clarification
+1 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 Thu, Apr 25, 2024 at 9:07 PM Jody Garnett wrote: > +1 thanks > > -- > Jody Garnett > > > On Thu, Apr 25, 2024 at 4:08 AM Peter Smythe wrote: > >> Following in the footsteps of GeoServer's GSIP-224, here is a similar >> proposal for GeoTools for the PMC to vote on please: >> >> >> https://github.com/geotools/geotools/wiki/Individual-contributor-clarification >> >> Proposed text, updating >> https://docs.geotools.org/latest/developer/procedures/contribution_license.html >> : >> >> All new contributors >>> <https://docs.geotools.org/latest/developer/roles/contributor.html> will >>> be required to grant copyright to the foundation using a Contributor >>> Licenses <https://www.osgeo.org/about/licenses/>: >> >> >>- >> >>individual_contributor >><https://www.osgeo.org/resources/individual-contributor-license/> >> >>- >> >>corporate_contributor >><https://www.osgeo.org/resources/corporate-contributor-license/> >> >> >> GeoTools is grateful that organizations of all shapes and sizes support >> our project with in-kind participation of their employees. Extending commit >> access is made to individuals directly based on their expertise >> demonstrated over time. >> >> >> Voting: >> >>- Andrea Aime: >>- Ian Turton: >>- Jody Garnett: >>- Nuno Oliveira: >>- Simone Giannecchini: >>- Torben Barsballe: >> >> >> Peter >> >> GeoServer PSC >> AWS Solutions Architect >> https://github.com/petersmythe >> >> >> On Wed, 10 Apr 2024 at 06:13, Jody Garnett >> wrote: >> >>> Proposal for discussion >>> https://github.com/geoserver/geoserver/wiki/GSIP-224 >>> >>> New text proposed for >>> https://docs.geoserver.org/latest/en/developer/policies/committing.html >>> page: >>> >>> All contributors are asked to provide an assignment agreement for >>> working on the project: >>> >>> >>>- individual_contributor >>> <https://www.osgeo.org/resources/individual-contributor-license/> >>> - Individual contributor agreement. >>> >>> >>> >>>- corporate_contributor >>> <https://www.osgeo.org/resources/individual-contributor-license/> >>> - Corporate contributor agreement to authorize employees to work >>> on project. May also be used as a software grant to donate software >>> to the >>> project. >>> >>> >>> GeoServer recognizes that organizations of all shapes and sizes support >>> our project with in-kind participation of their employees. Extending commit >>> access is made to individuals directly based on their expertise >>> demonstrated over time. >>> >>> >>> Thanks! >>> -- >>> Jody Garnett >>> ___ >>> Geoserver-devel mailing list >>> geoserver-de...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> ___ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geoserver-users] forwarding GEBCO WMS fails - help needed
On Wed, Apr 24, 2024 at 3:30 PM Roar Brænden wrote: > What I'm confused about is how the two classes should influence on what is > sent as Accept-header. Nothing in the code indicates something like that. > One is the built-in java client, the other the Apache one... I guess they might have different defaults, if no accept-header is specified? Just thinking out loud Cheers Andrea ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Regarding naming of rules derived from css
Hi Peter, as a community we accept code contributions only as pull requests. Can you turn those into PRs for the respective projects? 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 Fri, Apr 5, 2024 at 7:31 PM Segerstedt, Peter wrote: > Hi, we think your suggestions are great and have worked out an example > that hopefully could serve as documentation for the suggested change. > > Please see the attached .zip-file and following code changes: > > > https://github.com/sweco-sepesd/geoserver/blob/css_unique_rule_names/doc/en/user/source/styling/css/directives.rst > > > https://github.com/sweco-sepesd/geotools/commit/112199676f5371354db5c0dc7b960b2b3f022ca8 > > > > Regards, > > Peter > > > > *Från:* Andrea Aime > *Skickat:* den 7 mars 2024 17:08 > *Till:* Segerstedt, Peter > *Kopia:* geotools-devel@lists.sourceforge.net; Persson, Marcus < > marcus.pers...@sweco.se>; david.pers...@eskilstuna.se > *Ämne:* Re: [Geotools-devel] Regarding naming of rules derived from css > > > > Hi Peter, > > as a rule of thumb, we don't allow customer specific code in the > GeoTools/GeoServer codebase, > > if we did, we'd end up accumulating a massive amount of of variants in the > code that would make it > > even harder to maintain. The GeoServer changes look like a band-aid, too. > > > > Now, I think I get why you want unique names, but rather than working > around it in GeoServer, couldn't > > you have a CSS directive "@uniqueRules" in the CSS, that when used, makes > the CSS translator > > generate unique names directly? > > Also, again for the "not for one customer" rule, the functionality should > be properly documented > > to allow other users to make use of it (how to use it, why it's there). > > Try to write this documentation first, and if it's convincing for a wider > audience, then I see no problem in > > integrating the changes in the GeoTools CSS module. > > > > Regards, > > Andrea Aime > > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us > <https://urldefense.com/v3/__http:/bit.ly/gs-services-us__;!!HBVxBjZwpQ!zMjQSPlyyDsO4qgtPfs2HsyEB220ikIaneGcNwG2fwyzPt7TDJsXq-S-uOy4ob7F2LCLn7Ho0w-4QMMZoZmQ42CBGDsvaoyo4A8$> > 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/ > <https://urldefense.com/v3/__https:/www.geosolutionsgroup.com/__;!!HBVxBjZwpQ!zMjQSPlyyDsO4qgtPfs2HsyEB220ikIaneGcNwG2fwyzPt7TDJsXq-S-uOy4ob7F2LCLn7Ho0w-4QMMZoZmQ42CBGDsv6JfMDy0$> > > http://twitter.com/geosolutions_it > <https://urldefense.com/v3/__http:/twitter.com/geosolutions_it__;!!HBVxBjZwpQ!zMjQSPlyyDsO4qgtPfs2HsyEB220ikIaneGcNwG2fwyzPt7TDJsXq-S-uOy4ob7F2LCLn7Ho0w-4QMMZoZmQ42CBGDsv1Xq3l0E$> > > --- > > > 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
[Geotools-devel] GeoTools PMC Meeting notes, March 26th 2024
GeoTools / GeoServer PMC meeting - 2024-03-26Attending - Andrea Aime - Peter Smythe - Jukka Rahkonnen - Jody Garnett Actions from prior meetings: - Andrea: make a GSIP to amend the module graduation rules - Next meeting: - Interesting tile seeding speedup PR - Sponsorship update from Jody - jody: send invite to geoserver-security email list - jody to set up an rst-fix branch to collect fixes, ideally with automation of mkdocs_translate Agenda - GSIP 222 and 223 status - Tile creation speedup PR - mkdocs update - NetCDF dependency upgrade and backwards incompatibility - Chit chat Actions - GSIP 222 and 223 status GSIP 222, Graduating the Raster Attribute Table community module: - Approved, past 10 days with enough +0 and +1, no negatives - Andrea to make a PR to graduate the module GSIP 223, Community module graduation, amending generality rule - Approved, past 10 days with enough +0 and +1, no negatives - Andrea to make a documentation PR to update the procedures Tile creation speedup PR Bunch of PRs at various levels to speed up tile generation: - https://github.com/geosolutions-it/imageio-ext/pull/299 (sub-image encoding) - https://github.com/GeoWebCache/geowebcache/pull/1227 (improved concurrency) - https://github.com/geoserver/geoserver/pull/7457 - Enables the imageio-ext speedup - Encode first tile on the request thread, delegate the others to a secondary thread pool - Poor interaction with the mass-seed case, being worked on Good stuff, thank you Mitchell Bösecke! It has been a while since I've heard from him, we might have to complete the development. Problem with JMH tests. It should not be part of the quality test, because the GitHub actions/jenkins is not reliable. For reference, GDAL is also running performance tests, with 30% tolerance due to the unreliable environment. See mail thread https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg39829.html How to handle it: - @Ignore and let them be run interactively - Move them to the online profile? - Make yet another profile? - Add alongside other excludes: https://github.com/search?q=repo%3Ageoserver%2Fgeoserver+onlinetest+language%3A%22Maven+POM%22=code=Maven+POM Only two use cases in a large code base, likely to get forgotten… mkdocs update Collect the rst changes. Idea: - Start from https://github.com/geoserver/geoserver/pull/7462 - Remove the mkdocs - Collect the RSTs only - Share the load of fixing the RSTs across various people - Backport the changes - Actually run the mkdocs - https://github.com/jodygarnett/translate Here are the instructions for running translate script: 1. https://jodygarnett.github.io/translate/translate/migrate/ mkdocs_translate init mkdocs_translate scan mkdocs_translate migrate 2. Common problems: 1. Too much indenting (results in a block quote) 2. Stray results in the rest of the file being wrong 3. Examples also from previous RST PR: https://github.com/geoserver/geoserver/pull/7429/files#diff-7802f6ce973902c35df3d9c6670250c7191549c206ffbcccf20b6ae2582bb573L121 NetCDF dependency upgrade and backwards incompatibility I am sorry Steve, it does look like this is an actual compatibility break that cannot be addressed. - GRIB file configured in GeoServer 2.25 will not actually work in future GeoServer 2.26! - they changed 30-40 mapping tables in the library - name of the variable is constructed at runtime (not read from the file it is constructed from header and how time is understood) - Take down the layers and start from scratch; updates notes have instructions. Can we provide an option in the upgrade guide to just hand-edit the files instead? Only for single files… Extra details and examples here: https://osgeo-org.atlassian.net/browse/GEOT-7547 Chit chat CVE Disclosure feedback / articles showing up. - Difference between those seeking exposure vs to address an issue - ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] PMC meeting notes, March 12th 2024
GeoTools / GeoServer PMC meeting - 2024-03-12Attending - Torben Barsballe - Peter Smythe - Andrea Aime - Jody Garnett Actions from prior meetings: - N/A Agenda - GSIP 222: promote Raster Attribute Table module to extension - Amend community module graduation rules - Eclipse XSD is no more, and DescribeFeatureType fun - MkDocs effort update - GeoServer 2.25.0 release updates - Propose security breakout meeting ahead of 2.25.0 release Actions - Andrea: make a GSIP to amend the module graduation rules - Next meeting: - Interesting tile seeding speedup PR - Sponsorship update from Jody GSIP 222: promote Raster Attribute Table module to extension https://github.com/geoserver/geoserver/wiki/GSIP-222 - Almost all the boxes? Does not have three sites … - Jody proposed some alternate wording (see next topic) - RAT is in GDAL so “Stable Enough” - Jody would love to see this in the 2.25.0 release; but it would need everyone to respond with +1 or +0 before next week … - GeoServer is last tested with gdal 3.4.x, although some have used 3.8.x (for example) Votes and feedback welcomed! Amend community module graduation rules Existing rule is “okay”: https://docs.geoserver.org/latest/en/developer/policies/community-modules.html#id2 1. The module has at least a “handful” of users In order to avoid cluttering the main code base, only those community modules which are of interest to at least 3 users (this may include the maintainer) are promoted. Jody proposes some alternate text: 1. The module is not site specific and can be configured for use by the general GeoServer community. A community module of interest to multiple users would meet this goal; while a community module that has hard coded a domain name would not. Eclipse XSD is no more, and DescribeFeatureType fun “finally” :) Still not a lot of fun… - https://projects.eclipse.org/projects/modeling.mdt.xsd - project: https://eclipse.dev/modeling/mdt/?project=xsd - last download in 2014: https://eclipse.dev/modeling/mdt/downloads/?project=xsd - can see it in a recent release of Eclipse MDT (perhaps it was just merged): https://projects.eclipse.org/projects/modeling.mdt.xsd/reviews/2.32.0-release-review - Downloads? https://git.eclipse.org/c/emf/org.eclipse.emf.git/ - GitHub: https://github.com/eclipse-emf/org.eclipse.emf - Torben found it! GeoServer is very slow to generate a DescribeFeatureType response that involves thousands of layers, as it tries to build a single XSD schema object. - options: DescribeFeatureType “fast path”? This was done for GML output… - slowpart: is merging 1000 schemas into one XSD (wow) as the event system becomes complex. The overhead of event updates is wasted on GeoServer. - xml include? that is done for workspace … can the same approach be used for include feature type? Multi-workspace example: https://gs-main.geosolutionsgroup.com/geoserver/wfs?service=WFS=1.1.0=DescribeFeatureType Single workspace example: https://gs-main.geosolutionsgroup.com/geoserver/topp/wfs?service=WFS=1.1.0=DescribeFeatureType Jody suggested using “import” more, but that is mean to clients (forcing more requests and latency to avoid the 10 min waiting for events). Can we turn events off? Yes EMF allows it, but no XSD has it hardcoded as required (why?) MkDocs effort update The graph shows 50% tested, a small number of problem pages… But the problem pages really hard: - inline images - tables nested in lists Jody has this week in the clear to work on this activity: - Testing the remaining 49% - How can we help - ask the user-list again? - Can jody set up a shared branch to fix the rst pages, with some automation to publish the mkdocs (to gh-pages for example) how can we share common problems? - unexpected indent causing blockquote - lists indenting throwing off numbering - https://jodygarnett.github.io/translate/translate/migrate/#known-limitations action: jody to set up an rst-fix branch to collect fixes, ideally with automation of mkdocs_translate GeoServer 2.25.0 release updates Peter volunteers for the 2.25.0 release next week - this is a normal release - some extra care will be needed for the blog post - thank testers - document new features (see release candidate) - need a section on “internals” to thank Niels for resource store changes and link to developers guide ( https://docs.geoserver.org/latest/en/developer/programming-guide/config/resource.html ) - need a careful section for security vulnerability disclosure (see below) Andrea volunteers to do the geowebcache
Re: [Geotools-devel] Regarding naming of rules derived from css
Hi Peter, as a rule of thumb, we don't allow customer specific code in the GeoTools/GeoServer codebase, if we did, we'd end up accumulating a massive amount of of variants in the code that would make it even harder to maintain. The GeoServer changes look like a band-aid, too. Now, I think I get why you want unique names, but rather than working around it in GeoServer, couldn't you have a CSS directive "@uniqueRules" in the CSS, that when used, makes the CSS translator generate unique names directly? Also, again for the "not for one customer" rule, the functionality should be properly documented to allow other users to make use of it (how to use it, why it's there). Try to write this documentation first, and if it's convincing for a wider audience, then I see no problem in integrating the changes in the GeoTools CSS module. 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 Fri, Mar 1, 2024 at 12:51 PM Segerstedt, Peter wrote: > Thank you very much for the quick answer, things are rolling a bit slower > on this side. > > We’ll go ahead and polish the geotools proposal according to the procedure > so that rule-names can be populated from the css. > > However, for the application/usage scenario in quest, it’s crucial that > the rule names end up being unique. > The reason is that, depending on the current zoom-level in combination > with other choices in the application, we need to fine tune what rules are > rendered by the GetLegendGraphic-request. > > We are aware of the SCALE-parameter, but that is not sufficient in our > case, we need to specify the RULE-parameter as well. > > The css-to-sld transformation is very likely to produce a number of > "sld-rule-permutations" out of a single css-rule so even if we implement > the part in geotools, where @name is parsed from the css, the generated > SLD-rules will in many cases not end up being "unique in the context in > which they are defined"*. > > * https://portal.ogc.org/files/?artifact_id=22364 page 27 > > We've thought so far of two additional constraints: > > 1. Only apply "make-names-unique"-routine if there was a @name in the css. > 2. Make the "make-names-unique"-routine optional and activated based on > some setting, perhaps system property. > > What do you think - Would any of these suggested constraints make any > difference? > > Best Regards, > > Peter Segerstedt > > From: Andrea Aime > Sent: Friday, February 2, 2024 6:23 PM > To: Segerstedt, Peter > Cc: geotools-devel@lists.sourceforge.net; Persson, Marcus < > marcus.pers...@sweco.se>; david.pers...@eskilstuna.se > Subject: Re: [Geotools-devel] Regarding naming of rules derived from css > > Hi, > I'm the CSS module maintainer. Had a look at the changes. The GeoTools > change seems legit, it could be accepted > if it's contributed according to procedure (CLA, tests, documentation > updates). > > The GeoServer one seems to forcefully give a unique name to rules, if they > don't have one already. > We don't do that for SLD, it should not be done for other style languages > either. > Unless I'm misunderstanding it, I'm not inclined to accept such a change, > but let's talk. > > Best regards > Andrea > > > On Fri, Feb 2, 2024 at 2:23 PM Segerstedt, Peter via GeoTools-Devel > <mailto:geotools-devel@lists.sourceforge.net> wrote: > Dear developers, > > I've made, on the behalf of a customer, small additions to geotools and >
Re: [Geotools-devel] schema-agnostic postgis datastore ?
Hi Pierre,
having proper support for multiple schemas is something that has been on
the TODO list for a while.
Now, a simple, although incomplete, solution would be to track for each
feature type the origin schema,
and use it to build queries, when the schema has not been provided to the
store factory.
That however has a downside, that one cannot handle two same named tables
in different namespaces.
And no, we cannot use namespace as a way to track the schema, because
that's a parameter provided
from the outside, again to the store factory. Once provided, it must be
honored, failing to do so
would break backwards compatibility (and generally speaking, break a lot of
existing GeoServer installations,
where the namespace URI is always provided, and comes from the workspace
configuration in which the store is found).
Given that a Name is made of namespace URI and simple name only, there is
no place where the schema can be put
in a clean way. In a less clean way, the schema may become a prefix in the
name only, with all the limits of
a simple name built as "prefix:tableName" (potential conflicts if one
starts using your separator of choice in the
schema or table names). If not clean, this should at least be livable.
If you go this way, the prefixing should be enabled with a new optional
store parameter (w.g., schemaPrefix=true/false),
again for backwards compatibility.
A separate store is also an option, but everything in JDBCDataStore is
final, to avoid the temptation to write
custom database classes, so you'd be stuck having to replicate all the
code...
Anyone have any better ideas?
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, Mar 6, 2024 at 10:34 AM Pierre Mauduit <
pierre.maud...@camptocamp.com> wrote:
> Hello,
>
> I was willing to use the gt-postgis module to query a postgresql database
> where the data are stored inside different schema, and was surprised by the
> behaviour of the library in its current state.
>
> First, the module is able to find every relevant tables no matter the
> (database) schema it is stored into, but then trying to access the returned
> typenames lead to SQL query errors as it generally does not explicitely
> target the expected database schema.
>
> Considering a database with the following structure (schema.table):
>
> * nongeo.flup
> * fo.armoires
> * "savoie"."73-Savoie"
>
> And the following pseudocode (it is actually valid groovy code):
>
> import org.geotools.api.data.DataStoreFinder
> import org.geotools.api.data.Query
> import org.geotools.feature.NameImpl
>
> def ds = DataStoreFinder.getDataStore([
> "dbtype": "postgis",
> "host": "localhost",
> "port": 5432,
> "database": "mel",
> "user": "pmauduit",
> "passwd": "secret",
> ])
>
>
> println ds.getTypeNames()
>
> ds.getTypeNames().each {
> def fs = ds.getFeatureSource(it)
> println "${fs.getCount(Query.ALL)} features in ${it}"
> }
>
>
> The call to getTypeNames() will return [armoires, flup, 73-savoie] which I
> was expecting, meaning that the module was able to discover all the tables
> of interest from my database, no matter the schema they are nested in.
>
> But then the call to getFeatureSource() in the loop will fail, because the
> table is not in the search_path of my user, leading to the following
> warnings/errors:
>
> WARNING: Failure oc
[Geotools-devel] PMC meeting notes, February 27th 2024
GeoTools / GeoServer PMC meeting - 2024-02-27Attending - Peter Smythe - Jody Garnett - Torben Barsballe - Andrea Aime - Jukka Rahkonen - Kevin Smith Actions from prior meetings: - [Done] Peter: create a sed script to fix email addresses in sourceforge lists export - [Blocked] Jody: setup a github workflow to use dependency submission API <https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api> Agenda - Discourse - 2.25-RC Release coordination - Markdown migration update - Coordinated Vulnerability Disclosure stuffs - WFS GetFeatureResponse API change - Making ENTITY_RESOLUTION_ALLOWLIST default Actions - Discourse Peter was able to send an updated mbox to Vicky, we await a test instance. Wider OSGeo response has been: - finally! - huh why I like lots and lots of email 2.25-RC Release coordination Jody is set to release this week - thanks for everyone reviewing. Anything waiting: - Jody owes Niels a review - Gabe large catalog load improvement is almost ready: https://github.com/geoserver/geoserver/pull/7421 - Entity Resolution Allow below - GetFeatureResponse API - Stream of MapML pull-requests coming including vector tiles coming in Q: Is the mkdocs change needed for the release candidate? A: It would be nice to complete this and push out along side 2.25.0 release. Q: Can alex help? A: Release candidate is a poor introduction, but Jody will ask for help writing the release announcement. Markdown migration update Status and collaboration opportunities here: https://docs.google.com/spreadsheets/d/1HMqUpTirEwwSQfeNYikPjU0aFMl0-W4Xj44cg8V_VJA/edit#gid=0 List-table issue, Jody working on it. Looking good according to Andrea: https://jodygarnett.github.io/geoserver/data/raster/imagemosaic/configuration/#index-and-configuration-file-creation If you want to see markdown check branch (not a space for collaboration, just a way to check the current progress in markdown syntax): Checkout: - https://github.com/jodygarnett/geoserver/tree/mkdocs-preflight-test - Follow instructions here https://jodygarnett.github.io/translate/translate/migrate/ - todo: Jody can un gitignore the docs folder so people can see Coordinated Vulnerability Disclosure stuffs Peter needs access to the vulnerabilities page (done) Set to announce along side 2.25.0 release. Making ENTITY_RESOLUTION_ALLOWLIST default See https://github.com/geoserver/geoserver/pull/7444 Jody would like this for release, contains update instruction note. WFS GetFeatureResponse API change https://github.com/geoserver/geoserver/pull/7428 Andrea has some feedback: - if you do not return the supplier the api change will be minimal ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Pre-proposal discussion: adding alpha to ChannelSelection
On Wed, Feb 21, 2024 at 7:37 PM Jody Garnett wrote:
> That sounds good .. and surprising it is not there already? Is it just not
> a feature of SLD?
>
Indeed, as crazy as it sounds, it's not an SLD feature. This is an excerpt
from SE 1.1 schemas:
> Default method very much appreciated to be kind to implementations. For a
> default setter should it log a message, or throw a not implemented
> exception?
>
Yes. There is only one implementation, that will be updated, so the
exception should not be triggered in the practice.
> If you are making an API change perhaps attack the channel traversal
> problem directly with a default method to list all 4 channels...
>
The existing API is actually going to collaborate for this bit, here is
what we have in the style visitor:
/**
* Called when accept is called on a raster {@link ChannelSelection}
element
*
* @param cs the {@link ChannelSelection} to visit.
*/
void visit(ChannelSelection cs);
/**
* Called when accept is called on a raster {@link SelectedChannelType}
element
*
* @param sct the {@link SelectedChannelType} to visit.
*/
void visit(SelectedChannelType sct);
So it's up to the implementation to unpack the channel selection and call
the visit on the single channel selection type.
All existing implementations will be updated to call also on the new alpha
channel. No need for a new visit method here.
All in all, existing implementations not using the alpha channel should be
unaffected, which should help backporting this change.
Thoughts?
Cheers
Andrea
==
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
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Pre-proposal discussion: adding alpha to ChannelSelection
Hi all, I'm looking into channel selection, and in particular, to add the ability to specify an alpha channel along with either RGB or Gray. XML wise that would look as follows: 3 2 1 4 or: 3 4 Now... API wise this a bit annoying as ChannelSelection does not have a list of channels, but separate methods for the gray and RGB cases: https://github.com/geotools/geotools/blob/main/modules/library/api/src/main/java/org/geotools/api/style/ChannelSelection.java#L23 I would consider adding an alphaChannel getter/setter in that interface, with default implementation. Would that be ok? While it would not break compiling, it would still break semantics of visitors that care about channels (probably a minority) as they need to be updated to consider the new channel source. Would you consider this a blocker for backports? Code wise, I would expect to have to change the following: - Core interface and implementation - SLD 1.0 and 1.1 parser and encoder - CSS and eventually YSLD - The style builder in gt-browser - All visitors in GT/GS that care about channels (e..g, the duplicating one) - The grid coverage renderer to actually perform the selection What do you think? Cheers Andrea == 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 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Regarding naming of rules derived from css
Hi, I'm the CSS module maintainer. Had a look at the changes. The GeoTools change seems legit, it could be accepted if it's contributed according to procedure (CLA, tests, documentation updates). The GeoServer one seems to forcefully give a unique name to rules, if they don't have one already. We don't do that for SLD, it should not be done for other style languages either. Unless I'm misunderstanding it, I'm not inclined to accept such a change, but let's talk. Best regards Andrea On Fri, Feb 2, 2024 at 2:23 PM Segerstedt, Peter via GeoTools-Devel < geotools-devel@lists.sourceforge.net> wrote: > Dear developers, > > I've made, on the behalf of a customer, small additions to geotools and > geoserver in order to solve what's been previously discussed here: > > > https://gis.stackexchange.com/questions/452624/name-property-for-rules-in-css-styles-alternatives-or-how-to-contribute > https://sourceforge.net/p/geoserver/mailman/message/36050785/ > > The code should be publicly available here: > https://github.com/sweco-sepesd/geoserver/tree/geoserver_css_name_rule > ( > https://github.com/sweco-sepesd/geoserver/commit/7ed3780e377dcb0318bf9f44be2420d2f53d2639 > ) > > https://github.com/sweco-sepesd/geotools/tree/css_named_rule > ( > https://github.com/sweco-sepesd/geotools/commit/2a4d1afcbb6fac7ac9c7798946db50a627aff119 > ) > > Under what circumstances would it be possible for geotools/geoserver to > adopt these changes? > > Best Regards, > > Peter Segerstedt > > > > > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- 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 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Time to remove GDAL support from the OSX Github action?
That would be awesome Torben! Cheers Andrea On Tue, Jan 30, 2024 at 7:02 PM Torben Barsballe wrote: > As far as I'm aware, the conda GDAL distribution doesn't include java > bindings, which will be a problem. > I've built GDAL from source on Mac relatively recently, and might be able > to give a stab at porting that to the GitHub action, but no promises on > timeframe. > > Cheers, > Torben > > On Fri, Jan 26, 2024 at 7:22 AM Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> A little (gdal) bird told me we should try conda rather than brew. >> Anyone wants to try that out? >> >> Cheers >> Andrea >> >> On Thu, Jan 25, 2024 at 9:13 AM Jody Garnett >> wrote: >> >>> Thanks, >>> >>> I remember asking at a code sprint and the GDAL folks needed a volunteer >>> to publish out java bindings themselves. I did the build once a couple >>> years back; not sure what shape it is in now. >>> >>> I do not see Mac instructions in their manual at present: >>> https://gdal.org/api/java/index.html >>> -- >>> Jody Garnett >>> >>> >>> On Jan 24, 2024 at 11:23:57 PM, Roar Brænden >>> wrote: >>> >>>> Hi, >>>> >>>> I have some experience in using Mac and GDAL. It will not work by just >>>> using "brew install gdal", because that will not install the Java bindings. >>>> There was this other brew tap called "osgeo/osgeo4mac" that had a solution >>>> for the Java bindings, but I don't that works either. The solution for me >>>> was to build the GDAL libraries from sources, an even then there are some >>>> settings and tweaks to make it run with GeoTools. >>>> >>>> So my recommendation is to drop it. >>>> >>>> Regards, >>>> Roar Brænden >>>> >>>> >>>> >>>> >>>> 22. jan. 2024 kl. 20:05 skrev Jody Garnett : >>>> >>>> I can look at it after this release >>>> -- >>>> Jody Garnett >>>> >>>> >>>> On Mon, Jan 22, 2024 at 3:42 AM Andrea Aime < >>>> andrea.a...@geosolutionsgroup.com> wrote: >>>> >>>>> Hi al, >>>>> the OSX github action keeps on failing while installing GDAL. >>>>> Mark has made a valiant effort to try and get it going, which I truly >>>>> appreciate, but... it just keeps on failing. >>>>> >>>>> At this point, I vote for just pulling the GDAL installation from the >>>>> OSX action. >>>>> Objections? Ideas? Actions? >>>>> >>>>> Cheers >>>>> Andrea >>>>> >>>>> == >>>>> 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 >>>>> recipie
Re: [Geotools-devel] Time to remove GDAL support from the OSX Github action?
A little (gdal) bird told me we should try conda rather than brew. Anyone wants to try that out? Cheers Andrea On Thu, Jan 25, 2024 at 9:13 AM Jody Garnett wrote: > Thanks, > > I remember asking at a code sprint and the GDAL folks needed a volunteer > to publish out java bindings themselves. I did the build once a couple > years back; not sure what shape it is in now. > > I do not see Mac instructions in their manual at present: > https://gdal.org/api/java/index.html > -- > Jody Garnett > > > On Jan 24, 2024 at 11:23:57 PM, Roar Brænden > wrote: > >> Hi, >> >> I have some experience in using Mac and GDAL. It will not work by just >> using "brew install gdal", because that will not install the Java bindings. >> There was this other brew tap called "osgeo/osgeo4mac" that had a solution >> for the Java bindings, but I don't that works either. The solution for me >> was to build the GDAL libraries from sources, an even then there are some >> settings and tweaks to make it run with GeoTools. >> >> So my recommendation is to drop it. >> >> Regards, >> Roar Brænden >> >> >> >> >> 22. jan. 2024 kl. 20:05 skrev Jody Garnett : >> >> I can look at it after this release >> -- >> Jody Garnett >> >> >> On Mon, Jan 22, 2024 at 3:42 AM Andrea Aime < >> andrea.a...@geosolutionsgroup.com> wrote: >> >>> Hi al, >>> the OSX github action keeps on failing while installing GDAL. >>> Mark has made a valiant effort to try and get it going, which I truly >>> appreciate, but... it just keeps on failing. >>> >>> At this point, I vote for just pulling the GDAL installation from the >>> OSX action. >>> Objections? Ideas? Actions? >>> >>> Cheers >>> Andrea >>> >>> == >>> 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 >>> ___ >>> GeoTools-Devel mailing list >>> GeoTools-Devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >> ___ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> -- 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 dall
[Geotools-devel] Time to remove GDAL support from the OSX Github action?
Hi al, the OSX github action keeps on failing while installing GDAL. Mark has made a valiant effort to try and get it going, which I truly appreciate, but... it just keeps on failing. At this point, I vote for just pulling the GDAL installation from the OSX action. Objections? Ideas? Actions? Cheers Andrea == 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 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geoserver-devel] GeoTools / GeoServer PMC meeting - 2024-01-02
And of course I forgot the attachment. Here. Cheers Andrea On Wed, Jan 3, 2024 at 9:21 AM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > Ok, let's try to find out how much work that is. > > I believe inline styling can be found this way? > git grep "style\s*=\s*" -- "*.html" > /tmp/style.txt > > Result attached. That's 95 occurrences that need to be removed with > classes in geoserver.css, some like "display:none" can probably > be controlled by code instead (making the wicket component non visible). > > For local scripts, the following returns 17 occurrences: > > > git grep -i " community/gsr/src/main/resources/demos/dynamic_map_layer.html: src="<a rel="nofollow" href="https://js.arcgis.com/4.5/"">https://js.arcgis.com/4.5/"</a>;> > community/gsr/src/main/resources/demos/dynamic_map_layer.html: > community/gsr/src/main/resources/demos/layers-featurelayer-polygon.html: > <script src="<a rel="nofollow" href="https://js.arcgis.com/4.5/"">https://js.arcgis.com/4.5/"</a>;> > community/gsr/src/main/resources/demos/layers-featurelayer-polygon.html: > > > community/ogcapi/ogcapi-core/src/main/resources/swagger-ui/oauth2-redirect.html:<script> > extension/importer/web/src/main/java/org/geoserver/importer/web/ImportTaskTable$LayerPreviewPanel.html: > <script type="text/javascript"> > web/app/src/main/webapp/index.html:<script type="text/javascript"> > web/core/src/main/java/org/geoserver/web/GeoServerBasePage.html: > <script type="text/javascript" src="js/jquery.placeholder.js"> > web/core/src/main/java/org/geoserver/web/GeoServerBasePage.html: > > web/core/src/main/java/org/geoserver/web/GeoServerBasePage.html: > > web/core/src/main/java/org/geoserver/web/GeoServerLoginPage.html: > <script type="text/javascript"> > web/core/src/main/java/org/geoserver/web/admin/LogPage.html: <script > defer="defer" type="text/javascript"> > web/core/src/main/java/org/geoserver/web/system/status/JVMConsolePanel.html: > <script defer="defer" type="text/javascript"> > web/core/src/main/java/org/geoserver/web/wicket/ColorPicker.html: > <script type="text/javascript" src="js/jscolor/jscolor.js"> > web/core/src/main/java/org/geoserver/web/wicket/GeoServerTablePanel.html: >
Re: [Geotools-devel] [Geoserver-devel] GeoTools / GeoServer PMC meeting - 2024-01-02
Ok, let's try to find out how much work that is. I believe inline styling can be found this way? git grep "style\s*=\s*" -- "*.html" > /tmp/style.txt Result attached. That's 95 occurrences that need to be removed with classes in geoserver.css, some like "display:none" can probably be controlled by code instead (making the wicket component non visible). For local scripts, the following returns 17 occurrences: > git grep -i "https://js.arcgis.com/4.5/;> community/gsr/src/main/resources/demos/dynamic_map_layer.html: community/gsr/src/main/resources/demos/layers-featurelayer-polygon.html: