Re: [Geoserver-devel] [jira] (GEOS-6769) WFS 2.0.0 ListStoredQueries response is invalid
Thanks for your response Jody. I've posted my message on the standards mailing list. Met vriendelijke groet, Alex van den Hoogen - *Geodan* Buitenhaven 27-A 5211 TP 's-Hertogenbosch (NL) T +31 (0)73 - 5484 149 E alex.van.den.hoo...@geodan.nl www.geodan.nl | disclaimer http://www.geodan.nl/disclaimer/ - 2014-12-09 18:07 GMT+01:00 Jody Garnett jody.garn...@gmail.com: I would seek clarification from the other open-source projects on standa...@osgeo.org. Sounds like a muddle. On Tue, Dec 9, 2014 at 3:40 AM Alex van den Hoogen | Geodan alex.van.den.hoo...@geodan.nl wrote: Dear all, I'm still curious about this issue regarding WFS 2.0.0. I've discussed and read the standard with some of my colleagues and we are quite confused regarding this specific issue. First and foremost, in Geoserver the current implementation with an empty ReturnTypeFeature element is considered invalid. This is because this element is of the type QName, which must have contents according to the technical (XML) standards. However, we feel this is contradicted by the WFS 2.0.2 (most recent) standards document of the OGC. In chapter 14.3.4 Response (of ListFeatureQueries) it states that ReturnFeatureType must appear one or more times in the response. But this section also refers to 14.2 for a more extensive describtion of ReturnFeatureType. And here is where it gets really complicated. Strictly speaking 14.2 doesn't mention ReturnFeatureType but only the plural form ReturnFeatureTypes. So, if we treat those two elements as different items, we can conclude that there is no additional information regarding ReturnFeatureType and it just has to comply to xsd:QName, nothing more, nothing less. But if we treat both those elements as one, than ReturnFeatureType(s) is refered to in 14.2.2.5.2. Where a corrigendum is made in the form of: If the value of the returnFeatureTypes parameter is an empty string, this indicates that the stored query can return features of any type that the service offers.. Which clearly states that ReturnFeatureType can have an empty string and thus be an empty element. Only does this clash with xsd:QName and makes the response technically invalid XML. Also note that in the change request (CR 11-100) that is relevant to this change from 2.0.0 to 2.0.2, the submitter specifically mentions returnFeatureType (the singular word) and not returnFeatureTypes (plural). Coming back to the issue, you can probably see that we are quite confused regarding this issue, not even bringing up the fact if GeoServer should support WFS 2.0.0 or WFS 2.0.2. In which I guess 2.0.2 would be a better fit. Currently my question lies in whether what the GeoServer community thinks about this issue and maybe what we can do with it? Also what the most practical thing would be for GeoServer itself and still complying to the standards (whether 2.0.0 or 2.0.2)? Additional links: - WFS 2.0.2: http://docs.opengeospatial.org/is/09-025r2/09-025r2.html - WFS 2.0.0 CR 11-100: https://portal.opengeospatial.org/files/45707 (pdf) Thanks and kind regards, Alex van den Hoogen - *Geodan* Buitenhaven 27-A 5211 TP 's-Hertogenbosch (NL) E alex.van.den.hoo...@geodan.nl www.geodan.nl | disclaimer http://www.geodan.nl/disclaimer/ - 2014-11-18 10:49 GMT+01:00 Andrea Aime andrea.a...@geo-solutions.it: On Tue, Nov 18, 2014 at 10:04 AM, Alex van den Hoogen | Geodan alex.van.den.hoo...@geodan.nl wrote: Currently I'm quite unsure about this issue. Either GeoServer complies with the 2.0.2 standard of WFS, which is the current leading standard. But than there is a slight inconsistency about the version number. On the other hand, fixing this issue for every FeatureType is, I think, extremely difficult and would affect quite a lot of code. That's why I'm curious about other opinions. Especially from Justin and Andrea. Never looked into stored queries, so ... I don't have an opinion ready, I'd have to study the spec. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere
[Geoserver-devel] proposal: Layer with Service Security
Hello Group, There has been a request to allow a basic combination of layer and service security in the integrated geoserver security subsystem. I have made a proposal to that end: https://github.com/geoserver/geoserver/wiki/GSIP-125---Layer-with-Service-Security In summary, the proposal is to extend layer security to support service/operation specificity and leave the existing service security intact. As you can see in the proposal there is still a discussion to be had as to how certain rules will interact, but I have made a suggestion for what I think is the most logical solution. Please offer me your feedback. Kind Regards NIels -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] GeoServer 2.7-beta draft blog post available
Hi, for all those that can access wordpress, here is a link to the draft blog post for the 2.7-beta release: http://blog.geoserver.org/wp-admin/post.php?post=2070action=editmessage=10 Please integrate/review :-) Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Meeting minutes GeoTools/GeoServer meeting Jan 20 2015
GeoTools/GeoServer Meeting == Attending: - Jody - Andrea - Travis - Torbien - Jukka Agenda: 1. meeting time 2. sqlserver pull request 3. release status (review blog post) 4. release schedule 5. foss4g-na planning 1. meeting time --- 18:30 CET time 9:30 PST time done Send an email reminder :) Ben is missed... 2. sql server pull request --- Idea: Ask Ian replace the sql-server plugin and upload to SF (update blog post when ready). Jody will add +1 to email. It is not completly self contained (some modifications to a JDBC test). Leave this to email .. but hopefully to goes soon. 3. release status (review blog post) A few features are missing docs: - WPS clustering for asynch requests - Ian's changes - WFS 2.0 prepared query (Sampo) Todo: - GeoServer 2.7-beta: blog post is looking good. - GeoTools 13-beta - GeoServer 2.6.2 / GeoTools 12.2 - blog post anounced, twitter, ... email next 4. release schedule --- Double check: * https://github.com/geoserver/geoserver/wiki/Release-Schedule Consider bumping up 2.7.0 for foss4g-na? 5. foss4g-na planning - BOF session, maybe a small code-sprint (if that can be arranged). Sad about the conflict between foss4g-na and codesprint. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
Sounds like a good approach - we may also be able to use Java 7 Path API. I should also point out that we may be using this to figure out a the location of a *new* file (like one that does not exist yet). Perhaps the Java 7 path api can help. -- Jody -- Jody Garnett On 20 January 2015 at 15:28, Olle Markljung marklj...@gmail.com wrote: Ok, Perhaps it is not easy to say in what ways it all should work. Someone ought to be depending on the code doing this specific thing on Windows since the code exists. So, I got a proposition. What if we in DataUtilities.urlToFile do the same as DefaultResourceLocator.locateResource already does. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: Ok. Looking at the history I can't find anything that changed. Version of Java did change to 7. These urls also fail in GeoTools. It's not the usage of urlToFile in the test that's the problem but the usage of urlToFile in the DefaultResourceLocator.locateResource. The file:// is converted to // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com wrote: Yes, I see now that I was a bit unclear with my intentions of the last paragraph. However, I believe that the usage of the file protocol makes it unclear as when the file path will be interpreted as relative over absolute. I can get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- --
Re: [Geoserver-devel] [jira] (GEOS-6654) XLink moving to 1.1
So do I need to mark this as resolved (so it shows up in the 2.7-beta release notes?) -- Jody Garnett On 20 January 2015 at 00:48, Alex van den Hoogen | Geodan alex.van.den.hoo...@geodan.nl wrote: This issue has already been merged on the October 6, 2014. Although I can't edit it on JIRA as such. Same goes for GEOS-5391 (partial), GEOS-5993, GEOS-6883 (removed from JIRA?), GEOS-5993. Kind regards, Alex van den Hoogen - *Geodan* Buitenhaven 27-A 5211 TP 's-Hertogenbosch (NL) E alex.van.den.hoo...@geodan.nl www.geodan.nl | disclaimer http://www.geodan.nl/disclaimer/ - 2015-01-20 4:19 GMT+01:00 Jody Garnett (JIRA) j...@codehaus.org: Jody Garnett https://jira.codehaus.org/secure/ViewProfile.jspa?name=jgarnett *updated* an issue GeoServer https://jira.codehaus.org/browse/GEOS / [image: Bug] https://jira.codehaus.org/browse/GEOS-6654 GEOS-6654 https://jira.codehaus.org/browse/GEOS-6654 XLink moving to 1.1 https://jira.codehaus.org/browse/GEOS-6654 Change By: Jody Garnett https://jira.codehaus.org/secure/ViewProfile.jspa?name=jgarnett Fix Version/s: 2.7-beta Fix Version/s: 2.7-RC1[image: Add Comment] https://jira.codehaus.org/browse/GEOS-6654#add-comment Add Comment https://jira.codehaus.org/browse/GEOS-6654#add-comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) [image: Atlassian logo] -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
Ok, Perhaps it is not easy to say in what ways it all should work. Someone ought to be depending on the code doing this specific thing on Windows since the code exists. So, I got a proposition. What if we in DataUtilities.urlToFile do the same as DefaultResourceLocator.locateResource already does. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: Ok. Looking at the history I can't find anything that changed. Version of Java did change to 7. These urls also fail in GeoTools. It's not the usage of urlToFile in the test that's the problem but the usage of urlToFile in the DefaultResourceLocator.locateResource. The file:// is converted to // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com wrote: Yes, I see now that I was a bit unclear with my intentions of the last paragraph. However, I believe that the usage of the file protocol makes it unclear as when the file path will be interpreted as relative over absolute. I can get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant.
