[Geoserver-devel] [JIRA] (GEOS-8504) Wrong URL scheme in layer preview
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-8504 Wrong URL scheme in layer preview Issue Type: Bug Affects Versions: 2.12.1 Assignee: Unassigned Created: 21/Dec/17 3:58 PM Priority: Low Reporter: Olle Markljung The OpenLayers preview does not respect the URL scheme. It creates URLs to http despite being accessed through https. It's not enough to set the Proxy Base URL with https. This will render security errors in both Chrome and Internet Explorer. In Internet Explorer you can accept insecure content and it works anyway. It would be better if GeoServer used the URL scheme the client is using. An easy way is using instead of http: The browser will then use the scheme used for the containing page. Add Comment
[Geoserver-devel] [JIRA] (GEOS-7766) Add filter parsing to GetMap POST
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-7766 Add filter parsing to GetMap POST Issue Type: Improvement Affects Versions: 2.10-beta Assignee: Unassigned Created: 26/Sep/16 1:54 PM Environment: On master. Priority: Medium Reporter: Olle Markljung When doing a GetMap POST-request with a SLD constraining a NamedLayer the passed filter is parsed but not added to the request parse result. I test on master but I'm not sure if this has ever worked. We have an implementation that dates back to 2.1.3 that sends these filters. I haven't tested if it worked on that version. It is long gone. But the issue occurs on 2.4 and 2.7. Example. Should only show Broadway in blue. Shows all roads. "1.0" encoding="utf-8"?> xmlns:sld="http://www.opengis.net/sld" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:se="http://www.opengis.net/se" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" service="WMS" version="1.1.1" format="image/png" crs="EPSG:3011"> "1.0.0"> tiger:tiger_roads tiger_roads xmlns:ogc="http://www.opengis.net/ogc"> NAME Broadway line "http://www.opengis.net/gml/srs/epsg.xml#4326"> -74.02722 40.684221 -73.907005 40.878178 image/png false 476 768 XML
[Geoserver-devel] Charset in GetFeatureInfo header
Hi, We have an issue with a user of QGIS being unable to view GetFeatureInfo text/html responses correctly. I've checked that GeoServer correctly issues headers with Content-Type: text/html;charset=UTF-8 However, the client reading the response does not seem to read it. We can fix it by adding to a header.tpl file in /templates. Then QGIS is a happy camper displaying the response correctly. Since the content type is set correctly I believe GeoServer should be able to set the meta-tag too. This has been brought up before, http://sourceforge.net/p/geoserver/mailman/message/29359247/ I tried to inject the charset into the header.tpl processing and added to header.tpl. But I get an error: java.io.IOException: Error occured processing header template. Error occured processing header template. Error on line 11, column 20 in header.ftl Expecting a string, date or number here, Expression name is instead a freemarker.ext.beans.SimpleMethodModel I've never used Freemarker templates before.. Before I put down the time to fix it, would it be an accepted change anyway? Thanks, Olle Markljung -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] xlinks.xsd and GML 2
Ok, Andrea merged my PR and I guess the CITE-tests passed ( http://ares.opengeo.org/jenkins/job/cite-all/ right?). I was unable to run the CITE-tests myself on my windows machine. I'd like to backport the change to 2.7.x if that's OK with you guys. If so, I'll fix a new PR. I started to look at the swap to xlink 1.1 and it seems that Justin already started abit ( https://github.com/geoserver/geoserver/commit/ec437677677deadb3501f16dbf6e2309ff77a9f9 ). The new xsd was avaliable in gs-main but not used by any other xsd what I could see. I was able to swap everywhere but got held up by WFS-tests failing. I guess geotools needs to swap at the same time to match but I didn't get much further due to not beeing able to build geotools (an artefactory seems to be down). Has there been work/thoughts on this swap before? I'm also curious why there are three ways to import xlink throughout the code base. I guess referring to it locally will make it possible to build and use without internet but perhaps the same xlink.xsd could be referenced? If so, shouldn't all references be local? On Fri, Aug 21, 2015 at 7:08 PM, Jody Garnett jody.garn...@gmail.com wrote: Let's get some discussion going. Prepping the pull request can help, as can joining Skype meeting next Tuesday if it is not resolved by then. On Fri, Aug 21, 2015 at 7:35 AM Olle Markljung marklj...@gmail.com wrote: Ok. The clients problem is not the version but that different versions are imported at different places and both are declaring targetNamespace= http://www.w3.org/1999/xlink;. We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy. The difference between these versions is only that the use attribute is added on attribute-nodes. So, the problem is not the version but the mix of versions. The OGC-link says that http://www.w3.org/1999/xlink.xsd should be used and that differs from the versions above. I'd like to change the import reference in schemas/gml/2.1.2/geometry.xsd to target the xlinks.xsd in the same folder. I can provide a PR if it would likely be accepted. The question of complying to OGC is another issue. On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett jody.garn...@gmail.com wrote: I think the OGC changed some of this stuff, and I am not sure which one geoserver uses. Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema. On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung marklj...@gmail.com wrote: Hello We're experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType. I.e. http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.0.0request=DescribeFeatureTypetypeName=topp%3Astates The problem seems to be different includes of xlinks.xsd. http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd. It also includes geometry.xsd ( http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd) This file imports xlinks from ../../xlink/1.0.0/xlinks.xsd ( http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd) These two separate imports makes the WFS-client go bananas. Likely due to the fact that they are of different versions. If we alter geometry.xsd ( https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10) to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy. Does anyone know why two different versions are imported? -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- -- Jody Garnett -- -- Jody Garnett -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [JIRA] (GEOS-7167) Diverging xlinks imports for GML 2.1.2
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-7167 Diverging xlinks imports for GML 2.1.2 Issue Type: Bug Assignee: Unassigned Created: 22/Aug/15 8:32 AM Priority: Medium Reporter: Olle Markljung We're experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType. I.e. http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.0.0request=DescribeFeatureTypetypeName=topp%3Astates The problem seems to be different includes of xlinks.xsd. schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog (schemas/gml/2.1.2/xlinks.xsd). It also includes geometry.xsd (schemas/gml/2.1.2/geometry.xsd) This file imports xlinks from ../../xlink/1.0.0/xlinks.xsd (schemas/xlink/1.0.0/xlinks.xsd) These two separate imports makes the WFS-client go bananas. It does not allow that different versions are imported at different places and both are declaring targetNamespace=http://www.w3.org/1999/xlink. We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy. The difference between these versions is only that the use attribute is added on attribute-nodes. So, the problem is not the version but the mix of versions. Add Comment
Re: [Geoserver-devel] xlinks.xsd and GML 2
Ok. The clients problem is not the version but that different versions are imported at different places and both are declaring targetNamespace= http://www.w3.org/1999/xlink;. We can change to either schemas/xlink/1.0.0/xlinks.xsd (xlinks.xsd v3.0b2 2001-07) or schemas/gml/2.1.2/xlinks.xsd (xlinks.xsd v2.1.2 2002-07) and the client is happy. The difference between these versions is only that the use attribute is added on attribute-nodes. So, the problem is not the version but the mix of versions. The OGC-link says that http://www.w3.org/1999/xlink.xsd should be used and that differs from the versions above. I'd like to change the import reference in schemas/gml/2.1.2/geometry.xsd to target the xlinks.xsd in the same folder. I can provide a PR if it would likely be accepted. The question of complying to OGC is another issue. On Fri, Aug 21, 2015 at 2:00 PM, Jody Garnett jody.garn...@gmail.com wrote: I think the OGC changed some of this stuff, and I am not sure which one geoserver uses. Have a look at http://www.opengeospatial.org/blog/1597and let me know if it agrees with your experience. It could be either your client or geoserver needs to transition to official w3c xlink 1.1 Schema. On Fri, Aug 21, 2015 at 6:56 AM Olle Markljung marklj...@gmail.com wrote: Hello We're experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType. I.e. http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.0.0request=DescribeFeatureTypetypeName=topp%3Astates The problem seems to be different includes of xlinks.xsd. http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd. It also includes geometry.xsd ( http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd) This file imports xlinks from ../../xlink/1.0.0/xlinks.xsd ( http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd) These two separate imports makes the WFS-client go bananas. Likely due to the fact that they are of different versions. If we alter geometry.xsd ( https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10) to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy. Does anyone know why two different versions are imported? -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- -- Jody Garnett -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] xlinks.xsd and GML 2
Hello We're experiencing problems with XSD validation from a WFS-client when it is trying to use the info from DescribeFeatureType. I.e. http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.0.0request=DescribeFeatureTypetypeName=topp%3Astates The problem seems to be different includes of xlinks.xsd. http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd imports xlinks from the same catalog http://localhost:8080/geoserver/schemas/gml/2.1.2/xlinks.xsd. It also includes geometry.xsd ( http://localhost:8080/geoserver/schemas/gml/2.1.2/geometry.xsd) This file imports xlinks from ../../xlink/1.0.0/xlinks.xsd ( http://localhost:8080/geoserver/schemas/xlink/1.0.0/xlinks.xsd) These two separate imports makes the WFS-client go bananas. Likely due to the fact that they are of different versions. If we alter geometry.xsd ( https://github.com/geoserver/geoserver/blob/master/src/main/src/main/resources/schemas/gml/2.1.2/geometry.xsd#L10) to import xlinks.xsd from the same catalog as in feature.xsd everything is peachy. Does anyone know why two different versions are imported? -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [JIRA] (GEOS-7154) Some CQL geometric filters does not return features for WFS 1.1.0
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-7154 Some CQL geometric filters does not return features for WFS 1.1.0 Issue Type: Bug Assignee: Unassigned Created: 12/Aug/15 1:27 PM Environment: Windows, Tomcat 7 GS 2.7.1 and nightly (12-Aug-2015 08:20) Priority: Medium Reporter: Olle Markljung The filtering itself seems to be working since the number of matched features is correct. But it's only for filters DISJOINT and BEYOND the matched features are returned. I've only tested with the example polygon from the cql_tutorial.html against the topp:states sample data so I can only know that it doesn't work for DWITHIN, OVERLAPS, WITHIN and INTERSECTS since the others gives 0 matches. DWITHIN: http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.1.0request=GetFeaturetypeName=topp:statesoutputFormat=application%2FjsonCQL_FILTER=DWITHIN(the_geom%2C%20POLYGON((-90%2040%2C%20-90%2045%2C%20-60%2045%2C%20-60%2040%2C%20-90%2040)),%2010,%20meters) Results in totalFeatures: 38,features: [], OVERLAPS: http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.1.0request=GetFeaturetypeName=topp:statesoutputFormat=application%2FjsonCQL_FILTER=OVERLAPS(the_geom%2C%20POLYGON((-90%2040%2C%20-90%2045%2C%20-60%2045%2C%20-60%2040%2C%20-90%2040))) Results in totalFeatures: 12,features: [], WITHIN: http://localhost:8080/geoserver/topp/wfs?service=WFSversion=1.1.0request=GetFeaturetypeName=topp:statesoutputFormat=application%2FjsonCQL_FILTER=WITHIN(the_geom%2C%20POLYGON((-90
[Geoserver-devel] Layer preview charset
Hello, I'm having trouble previewing layers in GeoServer 2.7.1. It did not exist in 2.4.2. It occurs when previewing layers with special characters in its name. Probably related to https://osgeo-org.atlassian.net/browse/GEOS-4858 It did not work to change the document encoding of the OpenLayers3MapTemplate.ftl to UTF-8. The output format tries to return the response in UTF-8: OpenLayersMapOutputFormat.produceMap: --- template.setOutputEncoding(UTF-8); ByteArrayOutputStream buff = new ByteArrayOutputStream(); template.process(map, new OutputStreamWriter(buff, Charset.forName(UTF-8))); RawMap result = new RawMap(mapContent, buff, MIME_TYPE); return result; But, when looking at the response in Chrome I get a content type without charset information: Content-Type:text/html; subtype=openlayers The following resources ol3.js and ol.css are correctly served as Content-Type:application/x-javascript; charset=UTF-8 and Content-Type:text/css; charset=UTF-8 When looking at the response from the GetMap response and copying the content to a text editor I can see that the encoding of the document is UTF-8 without BOM. If I serve the same file locally (through IIS as plain html) I get the same behavior but when saving the document as UTF-8 I get a working layer preview page. Any ideas on how to get the RawMap result to render the charset=UTF-8 information to the browser? Regards, Olle Markljung -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Layer preview charset
Hi again, Adding meta charset=UTF-8 to the head of the ol3 template seems to solve the issue. I'll create a PR tonight for you to verify and hopefully you will allow a backport to the stable branch. Regards, Olle Markljung tis 26 maj 2015 kl. 15:51 skrev Olle Markljung marklj...@gmail.com: Hello, I'm having trouble previewing layers in GeoServer 2.7.1. It did not exist in 2.4.2. It occurs when previewing layers with special characters in its name. Probably related to https://osgeo-org.atlassian.net/browse/GEOS-4858 It did not work to change the document encoding of the OpenLayers3MapTemplate.ftl to UTF-8. The output format tries to return the response in UTF-8: OpenLayersMapOutputFormat.produceMap: --- template.setOutputEncoding(UTF-8); ByteArrayOutputStream buff = new ByteArrayOutputStream(); template.process(map, new OutputStreamWriter(buff, Charset.forName(UTF-8))); RawMap result = new RawMap(mapContent, buff, MIME_TYPE); return result; But, when looking at the response in Chrome I get a content type without charset information: Content-Type:text/html; subtype=openlayers The following resources ol3.js and ol.css are correctly served as Content-Type:application/x-javascript; charset=UTF-8 and Content-Type:text/css; charset=UTF-8 When looking at the response from the GetMap response and copying the content to a text editor I can see that the encoding of the document is UTF-8 without BOM. If I serve the same file locally (through IIS as plain html) I get the same behavior but when saving the document as UTF-8 I get a working layer preview page. Any ideas on how to get the RawMap result to render the charset=UTF-8 information to the browser? Regards, Olle Markljung -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] (GEOS-6870) Malformed Path to Resource on Windows
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-6870 Malformed Path to Resource on Windows Issue Type: Bug Assignee: Andrea Aime Created: 03/Feb/15 4:58 PM Fix Versions: 2.7-RC1 Priority: Major Reporter: Olle Markljung When running on Windows paths to resources are constructed that contains a mix of slashes and backslashes. Using such path will render an exception due to the fact that the Paths.VALID regex does not allow for backslashes to appear for paths to resources. I suggest that code is added that ensures only slashes are used in paths to resources when converted for a url in GeoServerDataDirectory.urlToResource. Add Comment
Re: [Geoserver-devel] windows build server failures on master
Yes, it checks if the file at the absolute path exists and if not assumes the path is relative. You could swap the order making the relative path default. Fail? The tests use paths to files that does not exist. The result will be that the path to the file will be relative. And that's the same result that you get on other platforms. But yes, if your intention is to use an absolute path to something that does not exist yet it will fail. So, by swapping the order you would get the absoulte file path as the default on windows as before for files that do not exist yet. But if there is a file there for the relative case that will be used instead. However that seems a bit unlikely. Should I update the PR to do that? Still not sure how the Java Path API would help here. /Olle On Sun, Feb 1, 2015 at 11:26 PM, Jody Garnett jody.garn...@gmail.com wrote: One of the lines in your pull request uses the test if (!f.exists()) This only works if the DataUtilities.urlToFile method is referring to a file that has been created yet. If we try the same logic on a file that does not exist yet it will fail... -- Jody Garnett On 1 February 2015 at 06:36, Olle Markljung marklj...@gmail.com wrote: Sorry for the delay. Ticket: http://jira.codehaus.org/browse/GEOT-4990 PR: https://github.com/geotools/geotools/pull/717 This builds clean using mvn clean install on my machine (building geotools). Should I communicate this on the geotools list as well? Not sure that I understand what you mean Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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
Re: [Geoserver-devel] windows build server failures on master
Sorry for the delay. Ticket: http://jira.codehaus.org/browse/GEOT-4990 PR: https://github.com/geotools/geotools/pull/717 This builds clean using mvn clean install on my machine (building geotools). Should I communicate this on the geotools list as well? Not sure that I understand what you mean Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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
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. http://p.sf.net/sfu
Re: [Geoserver-devel] windows build server failures on master
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. 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
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. /Olle måndag 19 januari 2015 skrev Andrea Aime andrea.a...@geo-solutions.it: On Mon, Jan 19, 2015 at 12:58 AM, Olle Markljung marklj...@gmail.com javascript:_e(%7B%7D,'cvml','marklj...@gmail.com'); wrote: Should file://images/rockFillSymbol.png be interpreted as equal to images/rockFillSymbol.png and ./images/rockFillSymbol.png? According to http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files you cannot use the file protocol with relative paths. So, perhaps this case shouldn't be supported and the test should fail. This approach has been working for years, people depend on it, so we are definitely not going to stop supporting it. You'll find that any suggestion intentionally breaking backwards compatibility will get a solid and immediate -1 around here ;-) 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
Re: [Geoserver-devel] windows build server failures on master
Ok!
I'll look into it.
/Olle
måndag 19 januari 2015 skrev Jody Garnett jody.garn...@gmail.com:
In this case we started with relative paths (and the base data directory)
and turned the results into absolute paths as part of the test to make sure
we are pointing at the right file.
The GeoTools method DataUtiltieis.urlToFile is what is being tested here,
and it is letting us down!
public static File urlToFile(URL url) {
if (!file.equals(url.getProtocol())) {
return null; // not a File URL
}
String string = url.toExternalForm();
if (string.contains(+)) {
// this represents an invalid URL created using either
// file.toURL(); or
// file.toURI().toURL() on a specific version of Java 5 on Mac
string = string.replace(+, %2B);
}
try {
string = URLDecoder.decode(string, UTF-8);
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(Could not decode the URL to UTF-8
format, e);
}
String path3;
String simplePrefix = file:/;
String standardPrefix = file://;
if (IS_WINDOWS_OS string.startsWith(standardPrefix)) {
// win32: host/share reference
path3 = string.substring(standardPrefix.length() - 2);
} else if (string.startsWith(standardPrefix)) {
path3 = string.substring(standardPrefix.length());
} else if (string.startsWith(simplePrefix)) {
path3 = string.substring(simplePrefix.length() - 1);
} else {
String auth = url.getAuthority();
String path2 = url.getPath().replace(%20, );
if (auth != null !auth.equals()) {
path3 = // + auth + path2;
} else {
path3 = path2;
}
}
return new File(path3);
}
As you can see we have one windows specific control path which we are not
testing anywhere else! I think I may refactor this code to *just* be string
based and take that windows flag as a parameter so we can test this on all
platforms ...
Note these methods were introduced when Java was doing a terrible job of
File to/from URL conversion. They have correcting things a bit with
file.toURI().toURL() ...
If you could grab the geotools codebase and set up a test case that passes
in the same strings that are failing in GeoServer it would be a great
help...
--
Jody
--
Jody Garnett
On 18 January 2015 at 15:58, Olle Markljung marklj...@gmail.com
javascript:_e(%7B%7D,'cvml','marklj...@gmail.com'); wrote:
Hi,
I can try to help. We use Windows and GeoServer at work.
But perhaps I need some guidance..
This is what the tests gives me. The failing one using file:// and the
successful one using ./
SLD attribute
file://images/rockFillSymbol.png
Linkage
file://images/rockFillSymbol.png
Converted to
\\images\rockFillSymbol.png
SLD attribute
./images/rockFillSymbol.png
Linkage
file:/C:/GitHub/geoserver/src/main/./target/default3970162196491181932data/styles/images/rockFillSymbol.png
Converted to
C:\GitHub\geoserver\src\main\target\default896598906399223139data\styles\images\rockFillSymbol.png
Should file://images/rockFillSymbol.png be interpreted as equal to
images/rockFillSymbol.png and ./images/rockFillSymbol.png?
According to
http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files
you cannot use the file protocol with relative paths.
So, perhaps this case shouldn't be supported and the test should fail.
/Olle
On Sun, Jan 18, 2015 at 9:05 PM, Jody Garnett jody.garn...@gmail.com
javascript:_e(%7B%7D,'cvml','jody.garn...@gmail.com'); wrote:
Okay we can consider it a goal for the year ( or a sprint activity if we
get a Windows volunteer ).
On Sun, Jan 18, 2015 at 12:01 PM Andrea Aime
andrea.a...@geo-solutions.it
javascript:_e(%7B%7D,'cvml','andrea.a...@geo-solutions.it'); wrote:
On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com
javascript:_e(%7B%7D,'cvml','jody.garn...@gmail.com'); wrote:
From Simone's email to getools-devel:
a while ago we agree on having a windows build server for geotools
which is reachable here:
http://winbuild.geo-solutions.it/jenkins
credentials are the same for the linux build server.
I was able to restore the build for geotools-devel, but it looks like
we have some failures for the geoserver master build target.
Failed tests:
testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest):
expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png
but was:\\images\rockFillSymbol.png
A general call out on this one, I would like to ensure we build
cleanly on windows (and take advantage of this machine that has been
provided).
Hi Jody,
the GeoServer windows build server has never been
Re: [Geoserver-devel] windows build server failures on master
Hi, I can try to help. We use Windows and GeoServer at work. But perhaps I need some guidance.. This is what the tests gives me. The failing one using file:// and the successful one using ./ SLD attribute file://images/rockFillSymbol.png Linkage file://images/rockFillSymbol.png Converted to \\images\rockFillSymbol.png SLD attribute ./images/rockFillSymbol.png Linkage file:/C:/GitHub/geoserver/src/main/./target/default3970162196491181932data/styles/images/rockFillSymbol.png Converted to C:\GitHub\geoserver\src\main\target\default896598906399223139data\styles\images\rockFillSymbol.png Should file://images/rockFillSymbol.png be interpreted as equal to images/rockFillSymbol.png and ./images/rockFillSymbol.png? According to http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files you cannot use the file protocol with relative paths. So, perhaps this case shouldn't be supported and the test should fail. /Olle On Sun, Jan 18, 2015 at 9:05 PM, Jody Garnett jody.garn...@gmail.com wrote: Okay we can consider it a goal for the year ( or a sprint activity if we get a Windows volunteer ). On Sun, Jan 18, 2015 at 12:01 PM Andrea Aime andrea.a...@geo-solutions.it wrote: On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com wrote: From Simone's email to getools-devel: a while ago we agree on having a windows build server for geotools which is reachable here: http://winbuild.geo-solutions.it/jenkins credentials are the same for the linux build server. I was able to restore the build for geotools-devel, but it looks like we have some failures for the geoserver master build target. Failed tests: testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest): expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png but was:\\images\rockFillSymbol.png A general call out on this one, I would like to ensure we build cleanly on windows (and take advantage of this machine that has been provided). Hi Jody, the GeoServer windows build server has never been made official because I did not manage to get the build working on Windows in a stable way (and got no help doing so either). I have a windows laptop now that I can use to do some bits on Windows, but honestly I despise the platform, so it's more call of duty than something I want to do in my spare time, it would need some champion that really pushes for it. Last time I checked there were some random failures in the WCS modules, failure to delete some files in the temp data dirs, I guess we are still keeping some reader/file handle open, but could not locate where. I guess it got worse from there. 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. ---
[Geoserver-devel] [jira] (GEOS-6748) PointPlacement with Rotation in TextSymbolizer gives NullPointerException
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-6748 PointPlacement with Rotation in TextSymbolizer gives NullPointerException Issue Type: Bug Assignee: Justin Deoliveira Components: Configuration, REST Created: 04/Nov/14 12:59 AM Priority: Minor Reporter: Olle Markljung When trying to create a SLD 1.0.0 style through the REST-API that contains a TextSymbolizer with a PointPlacement having Rotation you get a NullPointerException from the SLDTranslator. When creating the same SLD through the admin UI it validates fine and a correct style is created. While debugging I found that it demands an AnchorPoint. If AnchorPoint is provided the transform succeeds. According to the XSD and documentation this should not be needed. StyledLayerDescriptor.xsd ... xsd:element name=PointPlacement xsd:annotation xsd:documentation A PointPlacement specifies how a text label should be rendered relative to a geometric point. /xsd:documentation /xsd:annotation xsd:complexType xsd:sequence xsd:element ref=sld:AnchorPoint minOccurs=0/ xsd:element ref=sld:Displacement minOccurs=0/ xsd:element ref=sld:Rotation minOccurs=0/ /xsd:sequence /xsd:complexType /xsd:element ... Relevant stacktrace: Caused by: java.io.IOException: Error writing style
[Geoserver-devel] [jira] (GEOS-6749) Empty style file created on transform error
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-6749 Empty style file created on transform error Issue Type: Bug Affects Versions: 2.7-beta Assignee: Andrea Aime Components: REST Created: 04/Nov/14 1:03 AM Priority: Minor Reporter: Olle Markljung When posting a new style through the REST-API a new style file is created even though a transform error occurs. This new file is empty and needs to be removed in order to post a new style with the same name. It would be cleaner if no file is created if the style is not accepted. Add Comment
[Geoserver-devel] [jira] (GEOS-6747) Layer preview error for GML3.2
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-6747 Layer preview error for GML3.2 Issue Type: Bug Affects Versions: 2.6.0.1, 2.7-beta Assignee: Andrea Aime Components: Wicket UI Created: 01/Nov/14 4:51 PM Environment: Windows 7, Chrome, GeoServer 2.7-SNAPSHOT, Apache Tomcat/Jetty Priority: Trivial Reporter: Olle Markljung When selecting GML3.2 from the list of available WFS preview formats a missformated URL is created that throws an error. Selecting GML3.2 for tiger_roads creates the following URL: http://localhost:8080/geoserver/tiger/ows?service=WFSversion=1.0.0request=GetFeaturetypeName=tiger:tiger_roadsmaxFeatures=50outputFormat=application/gml+xml;%20version=3.2 And this gives the following error: ServiceExceptionReport xmlns=http://www.opengis.net/ogc xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance version=1.2.0 xsi:schemaLocation=http://www.opengis.net/ogc http
Re: [Geoserver-devel] Previewing style legend on the style page
Hi, Would it be possible to make this as a POST to GetLegendGraphic with payload (SLD_BODY) as the document being edited? Similar to WMS GetMap. A legend for WMS GetMap POST. Perhaps this is already supported? In this case it would be possible for outside usage. I could issue a GET but for gigantic SLD:s it would hit the browser URL length bounds. Regards, Olle Markljung On Wed, Mar 19, 2014 at 5:38 PM, Justin Deoliveira jdeol...@boundlessgeo.com wrote: On Wed, Mar 19, 2014 at 10:10 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: Hi, I'm looking into a request to add a legend preview in the style dialog, so that one can see how the legend would look like while editing the style. This would be similar, if you want, to the legend preview we have in the layers dialog, although it would not be possible to reuse the same code, as the legend is not yet saved here (the code in the layer page really calls a normal GetLegendGraphics instead) Interaction wise, it would be a preview button like the validate one I guess. Actually... another option would be to show the preview as a side effect of the user pressing the validation button. Opinions? My preference would be something explicit, do a dedicated button. $0.02 Cheers Andrea -- == Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK 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 --- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- *Justin Deoliveira* Vice President, Engineering | Boundless jdeol...@boundlessgeo.com @j_deolive https://twitter.com/j_deolive -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] (GEOS-6374) GetMapXmlReader allways uses default style for layergroup layers
Title: Message Title Olle Markljung created an issue GeoServer / GEOS-6374 GetMapXmlReader allways uses default style for layergroup layers Issue Type: Bug Affects Versions: 2.5-RC1 Assignee: Andrea Aime Attachments: layergroup-wrong-style.xml, tiger-giant_polygon_tiger-poly_landmarks_tiger-tiger_roads_tiger-poi.png, tiger-ny.png Created: 27/Feb/14 4:11 PM Labels: WMS Priority: Minor Reporter: Olle Markljung When making a GetMap POST request with XML body and having a layergroup as a NamedLayer the GetMapXmlReader take the default style for the layers in the layer group and not the configured one. I modified the example data for the layer group tiger-ny so that the poi-layer uses the default point style instead of the default poi style. When using GET GeoServer renders correctly. But with POST the default style is used despite the change in configuration. For POST the resolve of parameters gives me Styles = [StyleImpl[ name=giant_polygon], StyleImpl[ name=poly_landmarks], StyleImpl[ name=tiger_roads], StyleImpl[ name=poi
[Geoserver-devel] Null properties in GeoJSON
Hello, I was wondering about the reason why null properties are returned in GeoJSON and not in the default GML response. In my case the difference in payload are significant. Also, if there is a very good reason for this, would it be possible to add a new format option (much like the callback option) that disables the generation of null properties in the response? The code I'm looking at is in org.geoserver.wfs.response.GeoJSONOutputFormat at row 195-198. I'm grateful for any clarifying answer. Regards, Olle Markljung -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Null properties in GeoJSON
Thanks for the clarifying response. I'll look into providing a solution for this then. Regards, Olle Den 11/22/11 9:08 PM skrev Andrea Aime andrea.a...@geo-solutions.it: On Tue, Nov 22, 2011 at 2:39 PM, Olle Markljung olle.marklj...@astando.se wrote: Hello, I was wondering about the reason why null properties are returned in GeoJSON and not in the default GML response. In my case the difference in payload are significant. Also, if there is a very good reason for this, would it be possible to add a new format option (much like the callback option) that disables the generation of null properties in the response? The code I'm looking at is in org.geoserver.wfs.response.GeoJSONOutputFormat at row 195-198. The code was written a long time ago, so I'm not sure what the reasoning was. I can think of at least one good reason to have all the null values specified, which is the ability to determine the structure by looking at the first feature: geojson is schemaless, With this approach looking at the first feature you at least get to know what the attributes are without having to parse all the json, which is important if you are going to transform that json into something, like a shapefile or a database, that has a fixed structure (however one does not get the data type...). In any case, look at line 87-88, the code accesses the format_options parameter to determine wheter a json callback is required, or not. You can do the same and add a new format option allowing the writer to skip the null values. Assuming you call the option skipnulls the wfs call would then look like: request=GetFeaturetypeName=whateverformat_options=skipnulls:true Cheers Andrea -- --- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf --- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
