Re: [Geoserver-devel] Propose to add an option for latLongBoundingBox range checking before database query.
Interesting. I would normally expect the GeoTools datastore to handle this - but you are correct if you can tell up front that there is no data in the provided bounds you could avoid instantiating a datastore completely. A couple of notes of caution. Lat long bounding box is fairly lax, you may find it more accurate to project the request into the native projection and check against the native bounds. -- Jody Garnett On 4 February 2015 at 20:29, wrote: > Hi Geoserver community, > > For every WMS layer that has latLongBoundingBox set up in the config, > GeoServer may restrict the request to the configured latLongBoundingBox. At > the moment, it doesn't, and this results in unnecessary query and wastes > connections and cursors (for Oracle). > > Thus I propose to add an option in the code for latLongBoundingBox range > checking. the option will allow to filter the none result query which is > out of latLongBoundingBox range and improve the performance. > > If community reckon that it is the right way, I am willing to submit a > code patch to implement it if necessary. > > Thanks first, > > Lingbo > > > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Propose to add an option for latLongBoundingBox range checking before database query.
Hi Geoserver community, For every WMS layer that has latLongBoundingBox set up in the config, GeoServer may restrict the request to the configured latLongBoundingBox. At the moment, it doesn't, and this results in unnecessary query and wastes connections and cursors (for Oracle). Thus I propose to add an option in the code for latLongBoundingBox range checking. the option will allow to filter the none result query which is out of latLongBoundingBox range and improve the performance. If community reckon that it is the right way, I am willing to submit a code patch to implement it if necessary. Thanks first, Lingbo -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] (GEOS-6872) Propose to add an option for latLongBoundingBox range checking before database query.
Title: Message Title Lingbo Jiang created an issue GeoServer / GEOS-6872 Propose to add an option for latLongBoundingBox range checking before database query. Issue Type: Improvement Assignee: Andrea Aime Components: WMS Created: 04/Feb/15 10:24 PM Labels: wish Priority: Major Reporter: Lingbo Jiang Original Estimate: 4 days Remaining Estimate: 4 days Hi Geoserver community, For every WMS layer that has latLongBoundingBox set up in the config, GeoServer may restrict the request to the configured latLongBoundingBox. At the moment, it doesn't, and this results in unnecessary query and wastes connections and cursors (for Oracle). Thus I propose to add an option in the code for latLongBoundingBox range checking. the option will allow to filter t
Re: [Geoserver-devel] Format=application/openlayers Handling
That is a bit tricky David. Too bad you could not just display the layer titles in Open Layers? There is an open layers output format, it has recently been updated to OL3: * https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/map/OpenLayersMapOutputFormat.java * https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/resources/org/geoserver/wms/map/OpenLayers3MapTemplate.ftl -- Jody Garnett On 3 February 2015 at 11:48, Marks, David wrote: > Hello all, > > Can anyone point me to where the wms portion of GeoServer handles incoming > getMap requests where the format is set to use openLayers? > > As part of an ongoing project I've used the DispatcherCallback workflow to > hide the internal names of GeoServer layers, translating them in outgoing > getCapabilities responses and then re-interpreting them on incoming getMap > requests. However, testing has discovered the openLayers implementation in > GeoServer is somehow getting the original internal name and I'd like to > figure out how. > > Thanks, > David Marks > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Shutting down Thread Pools
I would be happy with Disposer. Please mark the FileWatcher thread pool as Daemon in anywise (as that was my intention when writing). -- Jody Garnett On 4 February 2015 at 12:45, Kevin Smith wrote: > I'd like to get this fixed soon. Does anyone have a problem with > documenting the limitations of the Disposer in terms of guaranteeing the > order of destruction? Failing that I'll go with the Daemon thread approach > which fixes the immediate problem and is otherwise no worse than the > current way things work, and has been used elsewhere. > > On 29 January 2015 at 11:32, Kevin Smith wrote: > >> Spring doesn't operate so much on the basis of registering things in an >> order as looking at the dependencies between bean definitions, then it >> comes up with an ordering based on that. To get the desired ordering >> requires that all beans declare that they depend on Disposer. The point of >> Disposer is to provide something that does work on a 'register for >> destruction' basis, so it might well make sense to have it do that >> destruction in reverse order of registration. >> >> I'm inclined to go with just making a best effort by having a few major >> components depend on it, and then document that anything needing guarantees >> about the order of destruction within the spring context beyond that should >> be using beans in the spring context rather than Disposer. >> >> On 27 January 2015 at 12:03, Ian Schneider >> wrote: >> >>> As for ordering, it appears that: >>> >>> "Based on the initialization order of beans, this same order will be >>> followed in reverse for consistency." >>> >>> So registering the Disposer first will ensure it gets called last. If >>> relative order is important (as you note, Kevin), components that require >>> 'late' disposal can register w/ the Disposer. >>> >>> On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith >>> wrote: >>> The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn't need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that's not good enough then proper disposal should be used instead. On 27 January 2015 at 00:51, Andrea Aime wrote: > On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith > wrote: > >> Yes, marking the threadpools as Daemon is the really trivial but >> kludgy way of doing it. The Disposer is the nicer but still a bit of a >> kludge way which as the benefit of not leaving the threadpools open after >> doing an undeploy. Making several additional classes Disposable so that >> they can cascade the disposal properly is the really nice and tidy way >> that >> involves a lot of work, and probably can't be backported. >> > > I did not look in the details, but the assesment of trying to do clean > disposing being hard feels right. > > The Disposer object is indeed a simpler solution, but it might have a > gotcha, what if anything > needs the object being disposed during the shutdown? > Is there any way to make sure the Disposer runs _last_ in the Spring > context shutdown order? > Or anything at the servlet specification level? > > 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 >
Re: [Geoserver-devel] Cascaded Stored Query update and question
Any update on the docs Sampo? We have the RC coming up on Feb 18th. At that point we will have a new 2.7.x branch (so any docs you do will need to be applied to both branches). -- Jody -- Jody Garnett On 8 January 2015 at 07:25, Sampo Savolainen wrote: > Hi, > > I've got the go-ahead from my client for me to use the hours for the > documentation. Is there a guide on how to write the docs? Or maybe just > point me to a good example I could follow? > > > Thanks, > Sampo > > On Mon, Dec 29, 2014 at 12:18 PM, Rahkonen Jukka (Tike) < > jukka.rahko...@mmmtike.fi> wrote: > >> Hi Sampo, >> >> By the release schedule it is 2015-01-18 >> https://github.com/geoserver/geoserver/wiki/Release-Schedule >> >> -Jukka Rahkonen- >> -- >> Sampo Savolainen wrote: >> >> Hi, >> >> Thanks Jody! Thanks for patching up the merge. I'll talk to my client >> to arrange the documentation. >> >> What's the deadline for 2.7.x feature freeze? >> >> >> Sampo >> >> On Wed, Dec 24, 2014 at 7:05 AM, Jody Garnett >> wrote: >> >>> Thanks Sampo, merged the work into master (just in time for christmas). >>> >>> Ran into two glitches: >>> >>> - GeoServerFeatureSource was having trouble copying query hints >>> (throwing illegal argument exception). I have patched the issue by logging >>> these errors for now. >>> - No docs (we can do that as a seperate pull request, even just to get >>> the new screens document). >>> >>> -- >>> Jody >>> >>>-- >>> Jody Garnett >>> >>> On 19 December 2014 at 03:25, Sampo Savolainen < >>> sampo.savolai...@spatineo.com> wrote: >>> Hi, I've now added temporary name support for my FeatureTypeCallback implementation. I think this should complete all the outstanding issues raised so far with this work. Here's the commit https://github.com/sampov2/geoserver/commit/7451f7949ce14f60e3e07cc341cf63a7bb986f79 Sampo On Tue, Dec 9, 2014 at 1:32 AM, Jody Garnett wrote: > > I went through and had a quick review of your pull request, a lot of > small comments (and a couple questions) but nothing immediately troubling. > > Can we get your FeatureTypeCallback question answered? I would like > to get this pull request sorted while you still have time/budget. > -- > Jody > >-- > Jody Garnett > > On 2 December 2014 at 06:31, Sampo Savolainen < > sampo.savolai...@spatineo.com> wrote: > >> Hi, >> >> A quick status update and a question: The GeoTools work is in a >> pull request that Jody has just about accepted. I've merged my GeoServer >> work with master and created a pull request for GeoServer ( >> https://github.com/geoserver/geoserver/pull/841). Comments please! >> >> >> There's been a good improvement in GeoServer regarding these types >> of special layers (these types = virtual tables + cascaded stored >> queries) >> in between the time when I originally wrote this and now. You've >> introduced >> the FeatureTypeCallback system so these kinds of layers can include their >> own logic inside these modules instead of polluting >> ResourcePool.getFeatureSource(). >> >> However, I'm a bit confused about the "temporary name" part in this >> pattern. I recall there was something similar before, but I can't >> remember >> what this was for. >> >> Looking at the API description for the callback, this functionality >> seems to be optional for the callback. As it stands, my feature ignores >> the >> temporary names and thus does no cleanup either. >> >> >> https://github.com/sampov2/geoserver/blob/2.7.x-feature-cascaded-stored-query/src/main/src/main/java/org/geoserver/catalog/CascadedStoredQueryCallback.java >> >> In what cases are these temporary names required? >> >> >> Sampo >> >> btw. If any of you are in London for GeoDATA 2014 on Thursday, come >> say hello. I'll be manning our stand there. >> >> -- >> Sampo Savolainen >> R&D Director, Spatineo Oy >> sampo.savolai...@spatineo.com >> +358-407555649 >> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland >> www.spatineo.com, twitter.com/#!/spatineo >> www.linkedin.com/company/spatineo-inc >> >> This message may contain privileged and/or confidential >> information. If you >> have received this e-mail in error or are not the intended recipient, >> you >> may not use, copy, disseminate, or distribute it; do not open any >> attachments, delete it immediately from your system and notify the >> sender >> promptly by e-mail that you have done so. >> >> >> -- >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Re
Re: [Geoserver-devel] Shutting down Thread Pools
I'd like to get this fixed soon. Does anyone have a problem with documenting the limitations of the Disposer in terms of guaranteeing the order of destruction? Failing that I'll go with the Daemon thread approach which fixes the immediate problem and is otherwise no worse than the current way things work, and has been used elsewhere. On 29 January 2015 at 11:32, Kevin Smith wrote: > Spring doesn't operate so much on the basis of registering things in an > order as looking at the dependencies between bean definitions, then it > comes up with an ordering based on that. To get the desired ordering > requires that all beans declare that they depend on Disposer. The point of > Disposer is to provide something that does work on a 'register for > destruction' basis, so it might well make sense to have it do that > destruction in reverse order of registration. > > I'm inclined to go with just making a best effort by having a few major > components depend on it, and then document that anything needing guarantees > about the order of destruction within the spring context beyond that should > be using beans in the spring context rather than Disposer. > > On 27 January 2015 at 12:03, Ian Schneider > wrote: > >> As for ordering, it appears that: >> >> "Based on the initialization order of beans, this same order will be >> followed in reverse for consistency." >> >> So registering the Disposer first will ensure it gets called last. If >> relative order is important (as you note, Kevin), components that require >> 'late' disposal can register w/ the Disposer. >> >> On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith >> wrote: >> >>> The only mechanism I can see to force ordering of destruction is to make >>> other beans depend on Disposer. Of course anything in a position to mark >>> itself as depending on Disposer doesn't need Disposer as it could just be a >>> DisposableBean itself and then dispose of its resources properly. We could >>> make a few significant components depend on Disposer to try to shunt it >>> down the list a reasonable distance and then document that once destruction >>> starts, registered objects might be destroyed at any time, and if that's >>> not good enough then proper disposal should be used instead. >>> >>> On 27 January 2015 at 00:51, Andrea Aime >>> wrote: >>> On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith wrote: > Yes, marking the threadpools as Daemon is the really trivial but > kludgy way of doing it. The Disposer is the nicer but still a bit of a > kludge way which as the benefit of not leaving the threadpools open after > doing an undeploy. Making several additional classes Disposable so that > they can cascade the disposal properly is the really nice and tidy way > that > involves a lot of work, and probably can't be backported. > I did not look in the details, but the assesment of trying to do clean disposing being hard feels right. The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything needs the object being disposed during the shutdown? Is there any way to make sure the Disposer runs _last_ in the Spring context shutdown order? Or anything at the servlet specification level? 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, copyin
Re: [Geoserver-devel] Author/publish vector tiles
On Wed, Feb 4, 2015 at 9:25 PM, Justin Deoliveira wrote: > Hey Tim, > > I've been looking at what it would take to add vector tile support in > GeoTools/GeoServer recently. Mostly looking at protocol buffers and how > they would integrate. All in all I think it would be pretty straight > forward, I did some pbf feature encoding for an r&d project a while back, > not vector tiles and not with GeoTools but I think the same approach could > be used. > I've also been looking at that. This library could help (with some fixes, just glancing over the code I've spotted at least one issue): https://github.com/ElectronicChartCentre/java-vector-tile > > Not sure if anyone else is working on this at the moment. But yeah, > funding always helps :) > Cannot confirm funding either but there is some interest around... whether it is going to turn into an actual development or not, it's yet to be seen. 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. --- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Author/publish vector tiles
Hey Tim, I've been looking at what it would take to add vector tile support in GeoTools/GeoServer recently. Mostly looking at protocol buffers and how they would integrate. All in all I think it would be pretty straight forward, I did some pbf feature encoding for an r&d project a while back, not vector tiles and not with GeoTools but I think the same approach could be used. Not sure if anyone else is working on this at the moment. But yeah, funding always helps :) -Justin On Wed, Feb 4, 2015 at 12:29 PM, Keane, Tim wrote: > New York City DoITT has interest in developing apps using vector > tiles to replace the use of Google Maps Engine and authoring tiles in > ArcGIS. > > > > Is the ability to author and publish vector tiles on the geoserver > roadmap? If so, is there a date? If not, does it need funding? > > > > -Tim Keane > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Author/publish vector tiles
New York City DoITT has interest in developing apps using vector tiles to replace the use of Google Maps Engine and authoring tiles in ArcGIS. Is the ability to author and publish vector tiles on the geoserver roadmap? If so, is there a date? If not, does it need funding? -Tim Keane -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ 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
Thanks for the discussion Olle, the fix has been merged. -- Jody Garnett On 3 February 2015 at 14:45, Olle Markljung wrote: > Yes it will. > But the problem here is that we do not know the intention of the user. > Existing code has a different handling of file:// urls on windows than on > other platforms. > On Windows file://images/poi.png will be converted into \\images\poi.png. > An absolute path to the host images. > On other platforms the same url will be converted into images/poi.png. A > relative path. > > So, by running existing code and se if we find a file at that location the > backwards compatibility will not be broken. > And by assuming relative path if no file exist you get the same result as > for other platforms. > > Since the Paths.VALID does not allow for backslashes "backslash (sorry > windows users we are following linux conventions here)" conversion code is > needed when converting URLs to resource in GeoServerDataDirectory.java. > If I add that the build is successful with mvn clean install. > I'll try to formulate a suiting JIRA and send a PR for the change. > > /Olle > > On Tue, Feb 3, 2015 at 2:26 AM, Jody Garnett > wrote: > >> Since (in GeoServer) we try to discourage the use of absolute paths I >> guess I am fine with the way things stand. >> >> If we were just focused on manipulating the file path in a safe manner >> the Java Paths API would help (since we actually want to check a file on >> disk I expect the Files API is fine). >> >> Correct me if I am wrong, and absolute path on windows will end up using >> the C:\ notation or the \\host\share\ notation - in both cases these are >> pretty specific and not confusable as a relative path? >> >> -- >> Jody Garnett >> >> On 2 February 2015 at 14:52, Olle Markljung wrote: >> >>> 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 >>> 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 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 > 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 >> 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. >
Re: [Geoserver-devel] WFS 2.0.0 and GML 3.1.1
On Tue, Feb 3, 2015 at 5:44 AM, Jonathan Meyer wrote:
> Is there a known issue with combining WFS 2.0.0 and GML 3.1.1? As far as
> I can tell, there isn't any reason this would be an unsupported
> combination. Testing on all currently available versions of GeoServer
> (2.5.4, 2.6.2, and 2.7beta) yield the same exception:
>
> http://www.opengis.net/ows/1.1"; xmlns:xsi
> ="http://www.w3.org/2001/XMLSchema-instance"; version="2.0.0"
> xsi:schemaLocation="http://www.opengis.net/ows/1.1
> http://localhost:8080/geoserver/schemas/ows/1.1.0/owsAll.xsd";>
>
>
> java.lang.RuntimeException: Failed to get property: {
> http://www.opengis.net/gml}featureMembers Failed to get property: {
> http://www.opengis.net/gml}featureMembers
> net.opengis.wfs20.impl.FeatureCollectionTypeImpl cannot be cast to
> net.opengis.wfs.FeatureCollectionType
>
>
>
>
>
> For reference I was making a GetFeature request with the following query:
>
>
> http://localhost:8080/geoserver/topp/ows?service=WFS&version=2.0.0&request=GetFeature&typeName=topp:tasmania_cities&count=50&outputFormat=text/xml;%20subtype=gml/3.1.1
>
> I also tried the query against WFS and global OWS service, as opposed to
> the virtual topp OWS.
>
Should be fixed for 2.7.x, 2.6.x and 2.5.x:
http://jira.codehaus.org/browse/GEOS-6134
Kudos to koordinates.com for sponsoring the fix
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.
---
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Security Decorator Issue
On Wed, Feb 4, 2015 at 1:00 PM, uros wrote: > Hi, > > I had problems using app-schema plugin with a security authorization module > I have written (using ResourceAccessManager). > I did some debugging and came to code that did some strange casting using > /org.geotools.data.DataStore/. > > Author of code is Andrea Aime and I am wondering if someone can review that > part of code. > > *org.geoserver.security.decorators.SecuredDataStoreInfo* > > method: DataStore getDataStore(ProgressListener listener) > > this method does return with following cast: > > /return (DataStore) SecuredObjects.secure(ds, policy);/ > > But there are situations when secure() returns DataAccess that can not be > cast to DataStore. > > What I did is I changed return type of getDataStore to DataAccess. That > solved my problem. > /DataAccess /is also return type of super /DecoratingStoreStoreInfo/ class > that /SecureDataStoreInfo /extends. > I believe you're the first one to use app-schema and the security subsystem at the same time... congratulations :-) The change you're proposing seems reasonable, can you make a pull request, on GitHub and for the master branch, for it? 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. --- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Security Decorator Issue
Hi, I had problems using app-schema plugin with a security authorization module I have written (using ResourceAccessManager). I did some debugging and came to code that did some strange casting using /org.geotools.data.DataStore/. Author of code is Andrea Aime and I am wondering if someone can review that part of code. *org.geoserver.security.decorators.SecuredDataStoreInfo* method: DataStore getDataStore(ProgressListener listener) this method does return with following cast: /return (DataStore) SecuredObjects.secure(ds, policy);/ But there are situations when secure() returns DataAccess that can not be cast to DataStore. What I did is I changed return type of getDataStore to DataAccess. That solved my problem. /DataAccess /is also return type of super /DecoratingStoreStoreInfo/ class that /SecureDataStoreInfo /extends. Configuration that I am using: GeoServer 2.5.2 with app-schema extension. Code is somehow complex (casting and generics), so suggestions are highly appreciated. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Security-Decorator-Issue-tp5185447.html Sent from the GeoServer - Dev mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Documentation cleanup/updates
Hi Mike, Here are some small things from the Jira for making you warm up: http://jira.codehaus.org/browse/GEOS-5509 Page that refers to non-existing tutorial. http://jira.codehaus.org/browse/GEOS-6431 http://jira.codehaus.org/browse/GEOS-6280 http://jira.codehaus.org/browse/GEOS-5708 http://jira.codehaus.org/browse/GEOS-6277 (new icons added later for points, lines, and polygons) A harder one about security: http://jira.codehaus.org/browse/GEOS-5928 http://jira.codehaus.org/browse/GEOS-5912 I am not sure how well http://docs.geoserver.org/stable/en/user/webadmin/security/auth.html and http://docs.geoserver.org/latest/en/user/security/index.html correspond. -Jukka Rahkonen- Mike Pumphrey wrote: > Hi all. Apologies for being away for a while. I have recently been given a > bit more time/space to contribute to GeoServer, and so my first thought > (unsurprisingly) was to see how the docs are doing. > So I just wanted to solicit a few opinions here on the -devel list to start > for those who have been closer to the project than I have been: * What are the major needs of the documentation as it exists now? * What are the major gaps in the documentation (stuff not in there that should be)? * Is it worth asking those two questions on the -users list as well? > I can't guarantee that I'll be able to spend oodles time on this right now, > but I can say that I can spend more time than I have been (which, granted, > isn't all that hard). Cheers! Thanks, Mike Mike Pumphrey User Advocate | Boundless m...@boundlessgeo.com 917-460-7213 http://boundlessgeo.com @boundlessgeo -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] (GEOS-6871) WFS claims not to support joins using or and not, but the underlying JDBC stores do
Title: Message Title Andrea Aime created an issue GeoServer / GEOS-6871 WFS claims not to support joins using or and not, but the underlying JDBC stores do Issue Type: Bug Assignee: Andrea Aime Components: WFS Created: 04/Feb/15 5:17 AM Priority: Major Reporter: Andrea Aime This is an artificial limitation imposed by the current join splitter Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
