You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(36) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(116) |
Feb
(68) |
Mar
(88) |
Apr
(135) |
May
(116) |
Jun
(66) |
Jul
(86) |
Aug
(70) |
Sep
(76) |
Oct
(64) |
Nov
(106) |
Dec
(90) |
2003 |
Jan
(131) |
Feb
(329) |
Mar
(264) |
Apr
(176) |
May
(252) |
Jun
(128) |
Jul
(301) |
Aug
(208) |
Sep
(221) |
Oct
(223) |
Nov
(237) |
Dec
(152) |
2004 |
Jan
(135) |
Feb
(217) |
Mar
(167) |
Apr
(248) |
May
(508) |
Jun
(327) |
Jul
(341) |
Aug
(263) |
Sep
(256) |
Oct
(299) |
Nov
(179) |
Dec
(155) |
2005 |
Jan
(157) |
Feb
(405) |
Mar
(379) |
Apr
(491) |
May
(664) |
Jun
(519) |
Jul
(382) |
Aug
(400) |
Sep
(403) |
Oct
(447) |
Nov
(334) |
Dec
(251) |
2006 |
Jan
(279) |
Feb
(198) |
Mar
(445) |
Apr
(330) |
May
(379) |
Jun
(310) |
Jul
(447) |
Aug
(581) |
Sep
(277) |
Oct
(647) |
Nov
(661) |
Dec
(656) |
2007 |
Jan
(393) |
Feb
(603) |
Mar
(568) |
Apr
(416) |
May
(411) |
Jun
(605) |
Jul
(595) |
Aug
(380) |
Sep
(350) |
Oct
(285) |
Nov
(342) |
Dec
(327) |
2008 |
Jan
(479) |
Feb
(489) |
Mar
(274) |
Apr
(465) |
May
(591) |
Jun
(491) |
Jul
(482) |
Aug
(305) |
Sep
(256) |
Oct
(307) |
Nov
(313) |
Dec
(323) |
2009 |
Jan
(340) |
Feb
(408) |
Mar
(515) |
Apr
(291) |
May
(582) |
Jun
(388) |
Jul
(421) |
Aug
(233) |
Sep
(337) |
Oct
(269) |
Nov
(308) |
Dec
(197) |
2010 |
Jan
(128) |
Feb
(149) |
Mar
(411) |
Apr
(315) |
May
(589) |
Jun
(477) |
Jul
(370) |
Aug
(174) |
Sep
(160) |
Oct
(205) |
Nov
(147) |
Dec
(174) |
2011 |
Jan
(296) |
Feb
(225) |
Mar
(255) |
Apr
(486) |
May
(684) |
Jun
(372) |
Jul
(253) |
Aug
(271) |
Sep
(173) |
Oct
(311) |
Nov
(187) |
Dec
(114) |
2012 |
Jan
(135) |
Feb
(70) |
Mar
(120) |
Apr
(100) |
May
(321) |
Jun
(250) |
Jul
(250) |
Aug
(328) |
Sep
(198) |
Oct
(237) |
Nov
(234) |
Dec
(208) |
2013 |
Jan
(190) |
Feb
(143) |
Mar
(138) |
Apr
(125) |
May
(181) |
Jun
(213) |
Jul
(289) |
Aug
(173) |
Sep
(92) |
Oct
(121) |
Nov
(114) |
Dec
(76) |
2014 |
Jan
(134) |
Feb
(185) |
Mar
(190) |
Apr
(211) |
May
(177) |
Jun
(143) |
Jul
(164) |
Aug
(130) |
Sep
(99) |
Oct
(106) |
Nov
(77) |
Dec
(180) |
2015 |
Jan
(233) |
Feb
(276) |
Mar
(281) |
Apr
(162) |
May
(165) |
Jun
(174) |
Jul
(119) |
Aug
(254) |
Sep
(185) |
Oct
(289) |
Nov
(186) |
Dec
(106) |
2016 |
Jan
(73) |
Feb
(102) |
Mar
(81) |
Apr
(223) |
May
(128) |
Jun
(169) |
Jul
(116) |
Aug
(196) |
Sep
(135) |
Oct
(144) |
Nov
(88) |
Dec
(74) |
2017 |
Jan
(100) |
Feb
(104) |
Mar
(112) |
Apr
(103) |
May
(103) |
Jun
(85) |
Jul
(128) |
Aug
(88) |
Sep
(56) |
Oct
(81) |
Nov
(79) |
Dec
(48) |
2018 |
Jan
(72) |
Feb
(39) |
Mar
(131) |
Apr
(95) |
May
(175) |
Jun
(135) |
Jul
(79) |
Aug
(58) |
Sep
(96) |
Oct
(116) |
Nov
(72) |
Dec
(62) |
2019 |
Jan
(87) |
Feb
(81) |
Mar
(94) |
Apr
(99) |
May
(106) |
Jun
(147) |
Jul
(87) |
Aug
(65) |
Sep
(90) |
Oct
(100) |
Nov
(59) |
Dec
(60) |
2020 |
Jan
(61) |
Feb
(74) |
Mar
(87) |
Apr
(110) |
May
(103) |
Jun
(48) |
Jul
(56) |
Aug
(45) |
Sep
(78) |
Oct
(39) |
Nov
(81) |
Dec
(39) |
2021 |
Jan
(55) |
Feb
(16) |
Mar
(43) |
Apr
(21) |
May
(35) |
Jun
(38) |
Jul
(14) |
Aug
(39) |
Sep
(49) |
Oct
(37) |
Nov
(21) |
Dec
(31) |
2022 |
Jan
(31) |
Feb
(26) |
Mar
(38) |
Apr
(35) |
May
(41) |
Jun
(17) |
Jul
(25) |
Aug
(21) |
Sep
(16) |
Oct
(11) |
Nov
(17) |
Dec
(18) |
2023 |
Jan
(20) |
Feb
(12) |
Mar
(43) |
Apr
(10) |
May
(38) |
Jun
(20) |
Jul
(24) |
Aug
(23) |
Sep
(33) |
Oct
(21) |
Nov
(17) |
Dec
(28) |
2024 |
Jan
(30) |
Feb
(20) |
Mar
(12) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Peter S. <gs...@sm...> - 2024-03-18 09:20:45
|
Oops, why was this not sent?!? The releases will be done over the next 2 days. Hi developers I'll be starting the GeoTools 31.0 and GeoServer 2.25.0 releases on Monday 18 March, so you have the next 48 hours to get those final fixes in. If anyone has feedback on the RC testing, please also submit that ASAP. Thanks Peter |
From: Andrea A. <and...@ge...> - 2024-03-14 18:14:03
|
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&version=1.1.0&request=DescribeFeatureType Single workspace example: https://gs-main.geosolutionsgroup.com/geoserver/topp/wfs?service=WFS&version=1.1.0&request=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: - Andrea has a docker image - Jody has is okay using gem bundle? https://github.com/GeoWebCache/gwc-release - jody has had trouble with xsddoc <https://sourceforge.net/projects/xsddoc/> Propose security breakout meeting ahead of 2.25.0 release - propose this time next week? yes - - write the security vulnerability section of the blog post - this will delay the release until 20 March action: - jody: send invite to geoserver-security email list |
From: Carsten K. <c....@da...> - 2024-03-12 08:03:35
|
Hi Jody, coming back to this quite late. Sorry for that. The project that requires these custom filter functions has already started and must be finished on July 1, 2024... It's a lot of work and I and my team are really busy now. Also, the SQL encodable custom filter functions is only a very small part of the project. Let me just focus on some of your questions: > * The proposal is not complete > o Tasks are not filled in; so I am not what is required, and if > you need help or collaborators to be successful > o API Change is not filled in so I do not know exactly what you > are proposing > As a response to my proposal I was expecting a discussion about how and where to implement the new interface(s). I thought, that API changes could be defined only afterwards. > * Have to be careful not get get dependencies from the function to > the datastore > o We cannot have a dependency from the function implementation, > to an interface in a specific datastore > o We should not assume the datastore is available on the > classpath , the function may be used on its own > o The FilterCapabilities are processed by GeoServer to come up > with a function list; need to ensure we do not mess that API > contract up. A lot of that contract will be in javadocs; > perhaps not expressed clearly (as they often assume > familiarity with the WFS specification > My first and simplest idea was to add a single GeoTools Core interface, which does not introduce a dependency from functions to datastores. AFAIK, Andrea came up with the idea to have several datastore specific tag interfaces (in order to address the problem that such functions only work with certain datastores). > Andrea pointed out a few places where we already know there is a > problem (some PostGIS specific functions) <-- this is a good test of > your proposed change? Can it handle these two functions and fix some > technical debt that occurred when we were not being careful about > function boundaries... No, that's likely not a good test of my proposed change, since I never intended to solve any existing problems in GeoTools. I just asked to add a new single interface in GT core and add this to the list of SQL encodable functions (like you already did with the NativeFilter class). Didn't think that there is much need for a BEFORE/AFTER API change discussion in advance. My proposal was about project specific externally implemented custom filter functions. These typically are only present in one single installation. So, why bothering about the fact, that these functions will only work in PostGIS and not in Oracle, when PostgreSQL is the project's only database? Of course I understand that you must account for the wider systems. And yes, often things thought simple are no longer that simple in a larger project. That may be true even for adding a new interface. I just have far too less knowledge about GeoTools internals. However, I guess that I do not have the time for attending this proposal any further (remind July 1, 2024 ... ). Instead, last night, I've found a surprisingly simple solution for my problem: I'm using a filter function that gets SQL encoded with PostGIS as the base class of my new custom filter functions. Since that must be a filter function with no custom visits (aka SQL encoding, see https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522), I decided to derive my filter function classes from FilterFunction_ceil: public abstract class MyCustomFilterFunction extends FilterFunction_ceil { public MyCustomFilterFunction ( FunctionNameImpl name, List<Expression> parameters, Literal fallback) { this.functionName = name; this.name = name.getName(); this.setParameters(parameters); this.setFallbackValue(fallback); } [...] } Since my filter function now is also an instance of FilterFunction_ceil, it gets encoded into SQL when the "encode function" option is set to true. In other words, I'm abusing class FilterFunction_ceil as the new tag interface I was asking for... Actually, this works great (and should not stop working until someone either removes FilterFunction_ceil or removes it from the list of SQL encodable functions for the PostGIS store). Nonetheless many thanks for your support. Maybe we could get back to this in the near future. Cheers Carsten |
From: Torben B. <tor...@gm...> - 2024-03-11 22:06:22
|
Reminder that the next PMC meeting is scheduled for tomorrow, March 12, at 18:30 <https://www.timeanddate.com/worldclock/fixedtime.html?year=2024&month=3&day=12&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215> CET. Note that North America has just switched to Daylight Savings Time while Europe has not yet, so this meeting will be at *10:30am* instead of 9:30am PDT for the North American folks this week. You can join the meeting by following this link: https://meet.osgeo.org/GeoServerMeeting Cheers, Torben |
From: Andrea A. <and...@ge...> - 2024-03-07 16:08:24
|
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 <pet...@sw...> 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 <and...@ge...> > Sent: Friday, February 2, 2024 6:23 PM > To: Segerstedt, Peter <pet...@sw...> > Cc: geo...@li...; Persson, Marcus < > mar...@sw...>; dav...@es... > 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:geo...@li...> 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://urldefense.com/v3/__https://gis.stackexchange.com/questions/452624/name-property-for-rules-in-css-styles-alternatives-or-how-to-contribute__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3FPtBZwU$ > > https://urldefense.com/v3/__https://sourceforge.net/p/geoserver/mailman/message/36050785/__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3esziWDI$ > > The code should be publicly available here: > > https://urldefense.com/v3/__https://github.com/sweco-sepesd/geoserver/tree/geoserver_css_name_rule__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3w1s0OxE$ > ( > https://urldefense.com/v3/__https://github.com/sweco-sepesd/geoserver/commit/7ed3780e377dcb0318bf9f44be2420d2f53d2639__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3FbMb_8w$ > ) > > > https://urldefense.com/v3/__https://github.com/sweco-sepesd/geotools/tree/css_named_rule__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz39_OE9-A$ > ( > https://urldefense.com/v3/__https://github.com/sweco-sepesd/geotools/commit/2a4d1afcbb6fac7ac9c7798946db50a627aff119__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3G7Ddl-c$ > ) > > Under what circumstances would it be possible for geotools/geoserver to > adopt these changes? > > Best Regards, > > Peter Segerstedt > > > > > _______________________________________________ > GeoTools-Devel mailing list > mailto:Geo...@li... > > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/geotools-devel__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3ZZJYxcw$ > > > > -- > Regards, > Andrea Aime > == > GeoServer Professional Services from the experts! > Visit > https://urldefense.com/v3/__http://bit.ly/gs-services-us__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3wDg4WZ8$ > for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > GeoSolutions Group > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > > https://urldefense.com/v3/__https://www.geosolutionsgroup.com/__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3C9cwAbU$ > > https://urldefense.com/v3/__http://twitter.com/geosolutions_it__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3iPZYfYU$ > ------------------------------------------------------- > > 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 > |
From: Andrea A. <and...@ge...> - 2024-03-07 15:28:46
|
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 < pie...@ca...> 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 occurred while looking up the primary key with finder: > org.geotools.jdbc.HeuristicPrimaryKeyFinder@4996c99 > org.postgresql.util.PSQLException: ERROR: relation "armoires" does not > exist > WARNING: Error occured determing srid for armoires.geom > [...] > org.postgresql.util.PSQLException: ERROR: relation "public.armoires" does > not exist > WARNING: Failed to retrieve information about public.armoires.geom by > examining the first sample geometry > org.postgresql.util.PSQLException: ERROR: relation "public.armoires" does > not exist > [...] > > I then skimmed into the codebase, looking for a way to have versions of > the classes that would be "schema-agnostic". I stumbled upon the > PostGisDialect class which looked as a good start, but was not sufficient > to circumvent my issue. So I began to relax some code enforcement (removing > final modifier on the JDBCDataStore class, copy/pasting code to get more > familiar with the codebase and how objects interact each other, ...), and > created a version of the objects (e.g. SchemaAwareJDBCDataStore, > SchemaAwareJDBCFeatureSource). I also stumbled upon the class being used to > represent typenames (NameImpl), and figured out it was mainly composed of a > namespaceURI, a separator and a localName, each being a String. So I > wondered why not considering the namespaceURI could be in our case the name > of the postgresql schema the table belongs to, even if it is not a "URI" > per se ? > > At this point, my current modifications are more of a PoC, but using a > custom parameter (schemaAware set to true in the params list), I could > switch to my custom version of the classes. As a result, using the > following pseudocode: > > def ds = DataStoreFinder.getDataStore([ > "dbtype": "postgis", > "host": "localhost", > "port": 5432, > "database": "mel", > "user": "pmauduit", > "passwd": "secret", > "schemaAware": true > ]) > > ds.getTypeNames().each { > def fs = ds.getFeatureSource(it) > println "${fs.getCount(Query.ALL)} features in ${it}" > > } > > will produce the following output: > > 56 features in fo.armoires > 4 features in nongeo.flup > 305 features in savoie.73-savoie > > But the getCount() is almost the only call working for now. > > To summarize, before getting further, here are some questions I am asking > myself and would have liked to share with you / have your inputs on it: > > * Is there any reason that I may have missed for the existing > implementation to react this way ? > * Am I on the right track with my approach and/or do you think I missed > some understandings on how the library is designed and works ? > * Would a custom JDBC datastore being able to be schema-agnostic of > interest for the project ? > > Thanks in advance for your inputs, > > Regards, > > -- > > Pierre Mauduit > > Ingénieur développement > > > Camptocamp France SAS 18 rue du Lac Saint André Savoie Technolac - > Bâtiment Le Dauphin F-73370 Le Bourget du Lac Tel. +33 (0)4 58 48 20 24 Fax > +33(0)4 58 48 20 10 www.camptocamp.com > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Pierre M. <pie...@ca...> - 2024-03-06 09:34:13
|
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 occurred while looking up the primary key with finder: org.geotools.jdbc.HeuristicPrimaryKeyFinder@4996c99 org.postgresql.util.PSQLException: ERROR: relation "armoires" does not exist WARNING: Error occured determing srid for armoires.geom [...] org.postgresql.util.PSQLException: ERROR: relation "public.armoires" does not exist WARNING: Failed to retrieve information about public.armoires.geom by examining the first sample geometry org.postgresql.util.PSQLException: ERROR: relation "public.armoires" does not exist [...] I then skimmed into the codebase, looking for a way to have versions of the classes that would be "schema-agnostic". I stumbled upon the PostGisDialect class which looked as a good start, but was not sufficient to circumvent my issue. So I began to relax some code enforcement (removing final modifier on the JDBCDataStore class, copy/pasting code to get more familiar with the codebase and how objects interact each other, ...), and created a version of the objects (e.g. SchemaAwareJDBCDataStore, SchemaAwareJDBCFeatureSource). I also stumbled upon the class being used to represent typenames (NameImpl), and figured out it was mainly composed of a namespaceURI, a separator and a localName, each being a String. So I wondered why not considering the namespaceURI could be in our case the name of the postgresql schema the table belongs to, even if it is not a "URI" per se ? At this point, my current modifications are more of a PoC, but using a custom parameter (schemaAware set to true in the params list), I could switch to my custom version of the classes. As a result, using the following pseudocode: def ds = DataStoreFinder.getDataStore([ "dbtype": "postgis", "host": "localhost", "port": 5432, "database": "mel", "user": "pmauduit", "passwd": "secret", "schemaAware": true ]) ds.getTypeNames().each { def fs = ds.getFeatureSource(it) println "${fs.getCount(Query.ALL)} features in ${it}" } will produce the following output: 56 features in fo.armoires 4 features in nongeo.flup 305 features in savoie.73-savoie But the getCount() is almost the only call working for now. To summarize, before getting further, here are some questions I am asking myself and would have liked to share with you / have your inputs on it: * Is there any reason that I may have missed for the existing implementation to react this way ? * Am I on the right track with my approach and/or do you think I missed some understandings on how the library is designed and works ? * Would a custom JDBC datastore being able to be schema-agnostic of interest for the project ? Thanks in advance for your inputs, Regards, -- Pierre Mauduit Ingénieur développement Camptocamp France SAS 18 rue du Lac Saint André Savoie Technolac - Bâtiment Le Dauphin F-73370 Le Bourget du Lac Tel. +33 (0)4 58 48 20 24 Fax +33(0)4 58 48 20 10 www.camptocamp.com |
From: Jody G. <jod...@gm...> - 2024-03-02 16:38:37
|
Those are for raster support, the rendering engine gt-render can draw rasters as well, and assume the many of the it.GeoSolutions plugins to hand geospatial rasters are available -- Jody Garnett On Fri, Mar 1, 2024 at 5:25 AM Amirhossein Nikfal <ah....@gm...> wrote: > I could run the Quickstart application > <https://docs.geotools.org/latest/userguide/tutorial/quickstart/maven.html> > without using Maven. My purpose was to get an understanding of what was > going on. > > Maven's dependency tree shows 97 modules for this application. However, > with only 22 ones out of these 97 modules, the application could be run > perfectly without any issue. So 75 modules seemed to be not-required. Among > them, there were 37 modules from *it.geosolutions*, 12 modules from > *org.geotools*, 7 modules from *com.google*, and many other unnecessary > modules. > > It would be appreciated if you clarify this for me. > > On Tue, Feb 27, 2024 at 5:50 PM Ian Turton <ijt...@gm...> wrote: > >> If you use maven it walks the dependency tree and finds all the jars it >> needs. >> >> Ian >> >> On Tue, 27 Feb 2024, 14:10 Amirhossein Nikfal, <ah....@gm...> >> wrote: >> >>> Yes, the problem was due to the missing of apache.commons.lang3. Thank >>> you very much. >>> >>> But how could I know about this dependency before the compilation? >>> Neither in the pom file, nor in the contents of the jar file >>> (gt-swing-31-SNAPSHOT.jar), there was no name regarding >>> apache.commons.lang3. Also "*mvn dependency:tree >>> -Dincludes=org.geotools:gt-swing:**" could not be helpful. >>> >>> Best, >>> Amir >>> >>> On Fri, Feb 23, 2024 at 4:37 PM Ian Turton <ijt...@gm...> wrote: >>> >>>> it looks like you haven't added (at least) the apache.commons.lang3 >>>> jar. This is what maven excels at so you should probably let it do it's >>>> magic rather than trying to muddle along with out it. >>>> >>>> Ian >>>> >>>> On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal <ah....@gm...> >>>> wrote: >>>> >>>>> The short code below can be compiled and run successfully, but *after >>>>> loading the shapefile*, shows error in line: FileDataStore store = >>>>> FileDataStoreFinder.getDataStore(file); >>>>> >>>>> This is the way I compile and run it: >>>>> java -d . Quickstart.java >>>>> java org.geotools.tutorial.quickstart.Quickstart >>>>> >>>>> Code: >>>>> package org.geotools.tutorial.quickstart; >>>>> >>>>> import java.io.File; >>>>> import org.geotools.api.data.FileDataStore; >>>>> import org.geotools.api.data.FileDataStoreFinder; >>>>> import org.geotools.swing.data.JFileDataStoreChooser; >>>>> >>>>> public class Quickstart { >>>>> public static void main(String[] args) throws Exception { >>>>> File file = JFileDataStoreChooser.showOpenFile("shp", null); >>>>> if (file == null) { >>>>> return; >>>>> } >>>>> FileDataStore store = FileDataStoreFinder.getDataStore(file); >>>>> } >>>>> } >>>>> >>>>> The errors: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder >>>>> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles >>>>> (*.shp):java.lang.NoClassDefFoundError: >>>>> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: >>>>> org/apache/commons/lang3/SystemUtils at >>>>> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) >>>>> at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) >>>>> at >>>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) >>>>> at >>>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) >>>>> at >>>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) >>>>> at >>>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) >>>>> at Quickstart.main(Quickstart.java:31)Caused by: >>>>> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils >>>>> at >>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) >>>>> at >>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) >>>>> ... 7 more* >>>>> >>>>> However, it can load the shapefile without problem when it's run by >>>>> maven: >>>>> mvn exec:java >>>>> -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart >>>>> >>>>> >>>>> Any comment would be appreciated. >>>>> _______________________________________________ >>>>> GeoTools-Devel mailing list >>>>> Geo...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>>> >>>> >>>> >>>> -- >>>> Ian Turton >>>> >>> _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Jody G. <jod...@gm...> - 2024-03-02 00:42:52
|
Release artifacts for your testing enjoyment: https://build.geoserver.org/view/release/job/geotools-release/118/artifact/build/release/distribution/31-RC/ -- Jody Garnett On Mar 1, 2024 at 3:58:17 PM, Jody Garnett <jod...@gm...> wrote: > Release train for GeoTools 31-RC! I collected a few of the PRs that have > come in (example [GEOT-7538] Use gt-http logging for request/response > <https://github.com/geotools/geotools/pull/4676> just in time). > > The new 31.x branch is created, although build jobs will take some time to > settle. > > Have a great weekend everyone. > -- > Jody Garnett > |
From: Jody G. <jod...@gm...> - 2024-03-01 23:58:32
|
Release train for GeoTools 31-RC! I collected a few of the PRs that have come in (example [GEOT-7538] Use gt-http logging for request/response <https://github.com/geotools/geotools/pull/4676> just in time). The new 31.x branch is created, although build jobs will take some time to settle. Have a great weekend everyone. -- Jody Garnett |
From: Amirhossein N. <ah....@gm...> - 2024-03-01 13:24:52
|
I could run the Quickstart application <https://docs.geotools.org/latest/userguide/tutorial/quickstart/maven.html> without using Maven. My purpose was to get an understanding of what was going on. Maven's dependency tree shows 97 modules for this application. However, with only 22 ones out of these 97 modules, the application could be run perfectly without any issue. So 75 modules seemed to be not-required. Among them, there were 37 modules from *it.geosolutions*, 12 modules from *org.geotools*, 7 modules from *com.google*, and many other unnecessary modules. It would be appreciated if you clarify this for me. On Tue, Feb 27, 2024 at 5:50 PM Ian Turton <ijt...@gm...> wrote: > If you use maven it walks the dependency tree and finds all the jars it > needs. > > Ian > > On Tue, 27 Feb 2024, 14:10 Amirhossein Nikfal, <ah....@gm...> > wrote: > >> Yes, the problem was due to the missing of apache.commons.lang3. Thank >> you very much. >> >> But how could I know about this dependency before the compilation? >> Neither in the pom file, nor in the contents of the jar file >> (gt-swing-31-SNAPSHOT.jar), there was no name regarding >> apache.commons.lang3. Also "*mvn dependency:tree >> -Dincludes=org.geotools:gt-swing:**" could not be helpful. >> >> Best, >> Amir >> >> On Fri, Feb 23, 2024 at 4:37 PM Ian Turton <ijt...@gm...> wrote: >> >>> it looks like you haven't added (at least) the apache.commons.lang3 jar. >>> This is what maven excels at so you should probably let it do it's magic >>> rather than trying to muddle along with out it. >>> >>> Ian >>> >>> On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal <ah....@gm...> >>> wrote: >>> >>>> The short code below can be compiled and run successfully, but *after >>>> loading the shapefile*, shows error in line: FileDataStore store = >>>> FileDataStoreFinder.getDataStore(file); >>>> >>>> This is the way I compile and run it: >>>> java -d . Quickstart.java >>>> java org.geotools.tutorial.quickstart.Quickstart >>>> >>>> Code: >>>> package org.geotools.tutorial.quickstart; >>>> >>>> import java.io.File; >>>> import org.geotools.api.data.FileDataStore; >>>> import org.geotools.api.data.FileDataStoreFinder; >>>> import org.geotools.swing.data.JFileDataStoreChooser; >>>> >>>> public class Quickstart { >>>> public static void main(String[] args) throws Exception { >>>> File file = JFileDataStoreChooser.showOpenFile("shp", null); >>>> if (file == null) { >>>> return; >>>> } >>>> FileDataStore store = FileDataStoreFinder.getDataStore(file); >>>> } >>>> } >>>> >>>> The errors: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder >>>> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles >>>> (*.shp):java.lang.NoClassDefFoundError: >>>> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: >>>> org/apache/commons/lang3/SystemUtils at >>>> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) >>>> at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) >>>> at >>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) >>>> at >>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) >>>> at >>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) >>>> at >>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) >>>> at Quickstart.main(Quickstart.java:31)Caused by: >>>> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils >>>> at >>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) >>>> at >>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) >>>> ... 7 more* >>>> >>>> However, it can load the shapefile without problem when it's run by >>>> maven: >>>> mvn exec:java >>>> -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart >>>> >>>> >>>> Any comment would be appreciated. >>>> _______________________________________________ >>>> GeoTools-Devel mailing list >>>> Geo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>> >>> >>> -- >>> Ian Turton >>> >> |
From: Segerstedt, P. <pet...@sw...> - 2024-03-01 11:51:34
|
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 <and...@ge...> Sent: Friday, February 2, 2024 6:23 PM To: Segerstedt, Peter <pet...@sw...> Cc: geo...@li...; Persson, Marcus <mar...@sw...>; dav...@es... 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:geo...@li...> 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://urldefense.com/v3/__https://gis.stackexchange.com/questions/452624/name-property-for-rules-in-css-styles-alternatives-or-how-to-contribute__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3FPtBZwU$ https://urldefense.com/v3/__https://sourceforge.net/p/geoserver/mailman/message/36050785/__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3esziWDI$ The code should be publicly available here: https://urldefense.com/v3/__https://github.com/sweco-sepesd/geoserver/tree/geoserver_css_name_rule__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3w1s0OxE$ (https://urldefense.com/v3/__https://github.com/sweco-sepesd/geoserver/commit/7ed3780e377dcb0318bf9f44be2420d2f53d2639__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3FbMb_8w$) https://urldefense.com/v3/__https://github.com/sweco-sepesd/geotools/tree/css_named_rule__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz39_OE9-A$ (https://urldefense.com/v3/__https://github.com/sweco-sepesd/geotools/commit/2a4d1afcbb6fac7ac9c7798946db50a627aff119__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3G7Ddl-c$) Under what circumstances would it be possible for geotools/geoserver to adopt these changes? Best Regards, Peter Segerstedt _______________________________________________ GeoTools-Devel mailing list mailto:Geo...@li... https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/geotools-devel__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3ZZJYxcw$ -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit https://urldefense.com/v3/__http://bit.ly/gs-services-us__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3wDg4WZ8$ for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://urldefense.com/v3/__https://www.geosolutionsgroup.com/__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3C9cwAbU$ https://urldefense.com/v3/__http://twitter.com/geosolutions_it__;!!HBVxBjZwpQ!wdN6haywN-0oMAqZAJScSYxbrRd78x11DMc-THOhPNxJsj7Qf8oOEqYL2MRt1R00SsIM9AAOqZIYZm-u1PIeonSdwrz3iPZYfYU$ ------------------------------------------------------- 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 |
From: Andrea A. <and...@ge...> - 2024-02-27 18:22:57
|
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 |
From: Ian T. <ijt...@gm...> - 2024-02-27 16:50:35
|
If you use maven it walks the dependency tree and finds all the jars it needs. Ian On Tue, 27 Feb 2024, 14:10 Amirhossein Nikfal, <ah....@gm...> wrote: > Yes, the problem was due to the missing of apache.commons.lang3. Thank you > very much. > > But how could I know about this dependency before the compilation? Neither > in the pom file, nor in the contents of the jar file > (gt-swing-31-SNAPSHOT.jar), there was no name regarding > apache.commons.lang3. Also "*mvn dependency:tree > -Dincludes=org.geotools:gt-swing:**" could not be helpful. > > Best, > Amir > > On Fri, Feb 23, 2024 at 4:37 PM Ian Turton <ijt...@gm...> wrote: > >> it looks like you haven't added (at least) the apache.commons.lang3 jar. >> This is what maven excels at so you should probably let it do it's magic >> rather than trying to muddle along with out it. >> >> Ian >> >> On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal <ah....@gm...> >> wrote: >> >>> The short code below can be compiled and run successfully, but *after >>> loading the shapefile*, shows error in line: FileDataStore store = >>> FileDataStoreFinder.getDataStore(file); >>> >>> This is the way I compile and run it: >>> java -d . Quickstart.java >>> java org.geotools.tutorial.quickstart.Quickstart >>> >>> Code: >>> package org.geotools.tutorial.quickstart; >>> >>> import java.io.File; >>> import org.geotools.api.data.FileDataStore; >>> import org.geotools.api.data.FileDataStoreFinder; >>> import org.geotools.swing.data.JFileDataStoreChooser; >>> >>> public class Quickstart { >>> public static void main(String[] args) throws Exception { >>> File file = JFileDataStoreChooser.showOpenFile("shp", null); >>> if (file == null) { >>> return; >>> } >>> FileDataStore store = FileDataStoreFinder.getDataStore(file); >>> } >>> } >>> >>> The errors: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder >>> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles >>> (*.shp):java.lang.NoClassDefFoundError: >>> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: >>> org/apache/commons/lang3/SystemUtils at >>> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) >>> at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) >>> at >>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) >>> at >>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) >>> at >>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) >>> at >>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) >>> at Quickstart.main(Quickstart.java:31)Caused by: >>> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils >>> at >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) >>> at >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) >>> ... 7 more* >>> >>> However, it can load the shapefile without problem when it's run by >>> maven: >>> mvn exec:java >>> -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart >>> >>> >>> Any comment would be appreciated. >>> _______________________________________________ >>> GeoTools-Devel mailing list >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >> >> >> -- >> Ian Turton >> > |
From: Amirhossein N. <ah....@gm...> - 2024-02-27 14:11:07
|
Yes, the problem was due to the missing of apache.commons.lang3. Thank you very much. But how could I know about this dependency before the compilation? Neither in the pom file, nor in the contents of the jar file (gt-swing-31-SNAPSHOT.jar), there was no name regarding apache.commons.lang3. Also "*mvn dependency:tree -Dincludes=org.geotools:gt-swing:**" could not be helpful. Best, Amir On Fri, Feb 23, 2024 at 4:37 PM Ian Turton <ijt...@gm...> wrote: > it looks like you haven't added (at least) the apache.commons.lang3 jar. > This is what maven excels at so you should probably let it do it's magic > rather than trying to muddle along with out it. > > Ian > > On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal <ah....@gm...> > wrote: > >> The short code below can be compiled and run successfully, but *after >> loading the shapefile*, shows error in line: FileDataStore store = >> FileDataStoreFinder.getDataStore(file); >> >> This is the way I compile and run it: >> java -d . Quickstart.java >> java org.geotools.tutorial.quickstart.Quickstart >> >> Code: >> package org.geotools.tutorial.quickstart; >> >> import java.io.File; >> import org.geotools.api.data.FileDataStore; >> import org.geotools.api.data.FileDataStoreFinder; >> import org.geotools.swing.data.JFileDataStoreChooser; >> >> public class Quickstart { >> public static void main(String[] args) throws Exception { >> File file = JFileDataStoreChooser.showOpenFile("shp", null); >> if (file == null) { >> return; >> } >> FileDataStore store = FileDataStoreFinder.getDataStore(file); >> } >> } >> >> The errors: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder >> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles >> (*.shp):java.lang.NoClassDefFoundError: >> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: >> org/apache/commons/lang3/SystemUtils at >> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) >> at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) >> at >> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) >> at >> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) >> at >> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) >> at >> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) >> at Quickstart.main(Quickstart.java:31)Caused by: >> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) >> ... 7 more* >> >> However, it can load the shapefile without problem when it's run by maven: >> mvn exec:java -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart >> >> >> Any comment would be appreciated. >> _______________________________________________ >> GeoTools-Devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > -- > Ian Turton > |
From: Torben B. <tor...@gm...> - 2024-02-26 20:30:13
|
Reminder that the next PMC meeting is scheduled for tomorrow, February 27, at 18:30 <https://www.timeanddate.com/worldclock/fixedtime.html?year=2024&month=2&day=27&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215> CET. You can join the meeting by following this link: https://meet.osgeo.org/GeoServerMeeting Cheers, Torben |
From: Ian T. <ijt...@gm...> - 2024-02-23 15:37:25
|
it looks like you haven't added (at least) the apache.commons.lang3 jar. This is what maven excels at so you should probably let it do it's magic rather than trying to muddle along with out it. Ian On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal <ah....@gm...> wrote: > The short code below can be compiled and run successfully, but *after > loading the shapefile*, shows error in line: FileDataStore store = > FileDataStoreFinder.getDataStore(file); > > This is the way I compile and run it: > java -d . Quickstart.java > java org.geotools.tutorial.quickstart.Quickstart > > Code: > package org.geotools.tutorial.quickstart; > > import java.io.File; > import org.geotools.api.data.FileDataStore; > import org.geotools.api.data.FileDataStoreFinder; > import org.geotools.swing.data.JFileDataStoreChooser; > > public class Quickstart { > public static void main(String[] args) throws Exception { > File file = JFileDataStoreChooser.showOpenFile("shp", null); > if (file == null) { > return; > } > FileDataStore store = FileDataStoreFinder.getDataStore(file); > } > } > > The errors: > > > > > > > > > > > > > > > *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder > getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles > (*.shp):java.lang.NoClassDefFoundError: > org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: > org/apache/commons/lang3/SystemUtils at > org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) > at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) > at > org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) > at > org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) > at > org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) > at > org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) > at Quickstart.main(Quickstart.java:31)Caused by: > java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 7 more* > > However, it can load the shapefile without problem when it's run by maven: > mvn exec:java -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart > > > Any comment would be appreciated. > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ian Turton |
From: Amirhossein N. <ah....@gm...> - 2024-02-23 14:48:24
|
The short code below can be compiled and run successfully, but *after loading the shapefile*, shows error in line: FileDataStore store = FileDataStoreFinder.getDataStore(file); This is the way I compile and run it: java -d . Quickstart.java java org.geotools.tutorial.quickstart.Quickstart Code: package org.geotools.tutorial.quickstart; import java.io.File; import org.geotools.api.data.FileDataStore; import org.geotools.api.data.FileDataStoreFinder; import org.geotools.swing.data.JFileDataStoreChooser; public class Quickstart { public static void main(String[] args) throws Exception { File file = JFileDataStoreChooser.showOpenFile("shp", null); if (file == null) { return; } FileDataStore store = FileDataStoreFinder.getDataStore(file); } } The errors: *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles (*.shp):java.lang.NoClassDefFoundError: org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError: org/apache/commons/lang3/SystemUtils at org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189) at org.geotools.data.shapefile.files.ShpFiles.<init>(ShpFiles.java:147) at org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260) at org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417) at org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78) at org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55) at Quickstart.main(Quickstart.java:31)Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 7 more* However, it can load the shapefile without problem when it's run by maven: mvn exec:java -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart Any comment would be appreciated. |
From: Ian T. <ijt...@gm...> - 2024-02-22 11:50:19
|
sounds good to me Ian On Thu, 22 Feb 2024 at 10:09, Andrea Aime <and...@ge...> wrote: > On Wed, Feb 21, 2024 at 7:37 PM Jody Garnett <jod...@gm...> > 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: > > <xsd:complexType name="ChannelSelectionType"> > <xsd:choice> > <xsd:sequence> > <xsd:element ref="se:RedChannel"/> > <xsd:element ref="se:GreenChannel"/> > <xsd:element ref="se:BlueChannel"/> > </xsd:sequence> > <xsd:element ref="se:GrayChannel"/> > </xsd:choice> > </xsd:complexType> > > >> 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ian Turton |
From: Jody G. <jod...@gm...> - 2024-02-22 10:31:27
|
Sounds good Andrea, I look forward to reviewing. Are you planning to get this in for the release candidate? -- Jody Garnett On Feb 22, 2024 at 2:07:59 AM, Andrea Aime < and...@ge...> wrote: > On Wed, Feb 21, 2024 at 7:37 PM Jody Garnett <jod...@gm...> > 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: > > <xsd:complexType name="ChannelSelectionType"> > <xsd:choice> > <xsd:sequence> > <xsd:element ref="se:RedChannel"/> > <xsd:element ref="se:GreenChannel"/> > <xsd:element ref="se:BlueChannel"/> > </xsd:sequence> > <xsd:element ref="se:GrayChannel"/> > </xsd:choice> > </xsd:complexType> > > >> 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 > |
From: Andrea A. <and...@ge...> - 2024-02-22 10:08:27
|
On Wed, Feb 21, 2024 at 7:37 PM Jody Garnett <jod...@gm...> 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: <xsd:complexType name="ChannelSelectionType"> <xsd:choice> <xsd:sequence> <xsd:element ref="se:RedChannel"/> <xsd:element ref="se:GreenChannel"/> <xsd:element ref="se:BlueChannel"/> </xsd:sequence> <xsd:element ref="se:GrayChannel"/> </xsd:choice> </xsd:complexType> > 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 |
From: Jody G. <jod...@gm...> - 2024-02-21 18:37:14
|
That sounds good .. and surprising it is not there already? Is it just not a feature of SLD? 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? If you are making an API change perhaps attack the channel traversal problem directly with a default method to list all 4 channels... -- Jody Garnett On Feb 21, 2024 at 10:26:41 AM, Andrea Aime < and...@ge...> wrote: > 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: > > <ChannelSelection> > <RedChannel> > <SourceChannelName>3</SourceChannelName> > </RedChannel> > <GreenChannel> > <SourceChannelName>2</SourceChannelName> > </GreenChannel> > <BlueChannel> > <SourceChannelName>1</SourceChannelName> > </BlueChannel> > <AlphaChannel> > <SourceChannelName>4</SourceChannelName> > </AlphaChannel> > </ChannelSelection> > > or: > > <ChannelSelection> > <GrayChannel> > <SourceChannelName>3</SourceChannelName> > </GrayChannel> > <AlphaChannel> > <SourceChannelName>4</SourceChannelName> > </AlphaChannel> > </ChannelSelection> > > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Andrea A. <and...@ge...> - 2024-02-21 18:27:06
|
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: <ChannelSelection> <RedChannel> <SourceChannelName>3</SourceChannelName> </RedChannel> <GreenChannel> <SourceChannelName>2</SourceChannelName> </GreenChannel> <BlueChannel> <SourceChannelName>1</SourceChannelName> </BlueChannel> <AlphaChannel> <SourceChannelName>4</SourceChannelName> </AlphaChannel> </ChannelSelection> or: <ChannelSelection> <GrayChannel> <SourceChannelName>3</SourceChannelName> </GrayChannel> <AlphaChannel> <SourceChannelName>4</SourceChannelName> </AlphaChannel> </ChannelSelection> 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 |
From: Jody G. <jod...@gm...> - 2024-02-15 07:40:25
|
GeoTools / GeoServer PMC meeting - 2024-02-13Attending - Peter Smythe - Gabriel Roldan - Jody Garnett - Torben Barsballe - Andrea Aime - Jukka Rahkonen - Kevin Smith Actions from prior meetings: - [DONE] Peter: Make a PR to update the PSC list (in the developers guide) gabe: Please help with review of #7156 - [DONE] Peter: Check-in with Brad to see how we can help/plan 🙂 - Peter: Share new wiki pages with the community - [WIP] gabe: Will make a PR for parallel loader - andrea: add peter to the security vulnerabilities issues Agenda - Release schedule - mkdocs update - Discourse update - github security advisory graph question - Worldwide installations of GeoServers - Firefox redirection - GEOS-11284 Promote community module "datadir catalog loader" to core - GEOT-7411 App-schema performance improvement in setting attribute values - SLD Arrow Regression - JNDI documentation critical fix - “www” no longer serving JS apps Actions - Peter: create a sed script to fix email addresses in sourceforge lists export - 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> - Release schedule GeoTools 29.5 / GeoServer 2.23.5 this month Need a volunteer - Andrea will ask around GeoSolutions but no promises. Fallback: Peter Next RC cycle (2.25) is also approaching. Adjusting release schedule to avoid extra 2.24 stable release… https://github.com/geoserver/geoserver/wiki/Release-Schedule Several potentially large changes outstanding: - Wicket 9 <https://github.com/geoserver/geoserver/pull/7154> (postpone to 2.26) - Resources and Paths API <https://github.com/geoserver/geoserver/pull/7156> - one legit bug on windows - Firefox redirectionand stuck on difference of opinion on API meaning (need to clarify javadoc) - action: gabe: volunteer to check in on this later in the month (breakout meeting) - startup enhancements (should be good) - mkdocs (branch <https://github.com/geoserver/geoserver/tree/mkdocs>) (timing would be good) sidebar: Handling of WPS results with respect of ResourceStore and multiple containers - there is some other way to handle that, can check system property - ideally a blob storage would be good for shared WPS output - Configure in WPS administration panel, where to share output mkdocs update Download directives now work: https://jodygarnett.github.io/geoserver/introduction/license/ - docs/introduciton/download/download.txt - lists “external” files - docs/introduction/download/.gitignore - to avoid storing duplicate files - mkdocs.yml has a hook to code to read download.txt above Example of using {{ version }} and {{ release }}: - https://jodygarnett.github.io/geoserver/installation/docker/ - Short term {{ release }} - Jody would like to grab these from pom.xml (this would be a change to release procedure) - Or can we determine from git history - I cannot determine with git because our tags are not on our branch, ours are not :) Can we convert the chinese docs: - yes we could, there is a language chooser - can convert chinese docs later, run the script, need a native speaker to review - jody has a script to convert language, but need a native speaker to review results Discourse update https://trac.osgeo.org/osgeo/ticket/3104#comment:7 Migration broken by SF anonymization… Action: Peter to create a sed script to fix email addresses github security advisory graph question A change to a published vulnerability came in from Mark: - https://github.com/github/advisory-database/pull/3483 - Q: why is this not being made to our geoserver one? Fundamental questions: - For a vulnerability in gs-web-core … - Do we also record gs-web-app? For the war overlay use? - Do we also record against the war for download use - Do we also record against the windows installer … - Would this change for wps extension? Jody’s expectation is to write down the most specific thing … and trust the tools The answer provided by dependabot is a github action, that would run for each tag, that would publish the “graph” based on the pom.xml file relationships. - https://github.com/dependabot/dependabot-core/issues/2640 - No it does not handle maven pom.xml directly, there is an action that processes the dependency:tree into the “graph” used by the tools - would it be smart enough for profiles? action: 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> Worldwide installations of GeoServers Nope: https://www.geoseer.net/ (also https://www.geoseer.net/blog/?p=2020-06-04_geospatial_server_software ) SourceForge downloads used to give some view GeoServer - Browse /GeoServer at SourceForge.net <https://sourceforge.net/projects/geoserver/files/GeoServer/> but people are installing by other means as well. Note docker is downloading extensions from SF on each startup (almost like a phone home) Firefox redirection Not quite sure where the problem is, Jody uses firefox for testing and has not noticed anything. Jukka made a test. Works for him with GS 2.24.2 and Firefox version 115.7.0esr GEOS-11284 Promote community module "datadir catalog loader" to core Gabe is working, and has three things left (app-schema, sld-service, metadata …) - Has been adding tests, and finding glitches - The update process was setting up info’s with reference to the “old” (non updated) catalog GEOT-7411 App-schema performance improvement in setting attribute values Same failures as without the changes. Gabriel to look into fixing some of the existing failures too! SLD Arrow Regression It looks like this was not noticed during release-candidate testing (which is when we allocate some time to fix regressions), Checking around everyone is indeed using; resource time/funding would be required to make this more general again. JNDI documentation critical fix Critical? JNDI tomcat documentation properties was incorrect: - Our docs indicate Tomcat JNDI setting uses maxActive - Tomcat 8 now uses maxTotal - …. quiet about ignoring the old maxActive setting, defaulting to 8 connections Docs are now fixed: - https://github.com/geoserver/geoserver/pull/7417 - https://docs.geoserver.org/latest/en/user/tutorials/tomcat-jndi/tomcat-jndi.html#tomcat-setup Action: Highlight in release notes “www” no longer serving JS apps https://github.com/geoserver/geoserver/pull/7420 That is probably a consequence of recent header changes Discussion: - Feedback is to have a setting to disable FilePublisher (www folder), rather than force all content there to text/html (which defeats the reason to have a www folder). - Discussion will continue on PR |
From: Torben B. <tor...@gm...> - 2024-02-12 20:56:10
|
Reminder that the next PMC meeting is scheduled for tomorrow, February 13, at 18:30 <https://www.timeanddate.com/worldclock/fixedtime.html?year=2024&month=2&day=13&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215> CET. You can join the meeting by following this link: https://meet.osgeo.org/GeoServerMeeting Cheers, Torben |