Re: [Geoserver-devel] Questions about Dynamic Symbolizers

Andrea,
remember we talked about the implicancies of updating the external graphics
based on last modified time as you well described, but sort of agreed a good
comprimise solution would be to just update the cache on a config reload. We
could also set a global, fixed and configurable expiry time as to reduce the
amount of checks for modifications.
Cheers,
Gabriel
On Wednesday 31 December 2008 08:47:07 Andrea Aime wrote:
> mfrumin ha scritto:
> > Hey all, check out my first experiment with this awesome new feature:
> >
> > http://transit.frumin.net/subway/spark.php
> >
> > but I have a couple of questions:
> >
> > 1. can this work fully vectorized? if my dynamic symbolizers were
> > vectors (SVG? PDF?) would it work? this way the whole thing can
> > be rendered as a nice PDF and printed on a large plotter to hang
> > on my wall...
>
> Not at the moment, whatever the source form is, it gets rasterized
> before entering the rendering pipeline. The reason is simple, it's a lot
> faster.
> It's possible to bring vector data up to the final rendering stages,
> but it would require some changes in the rendering chain, and a
> parameter to control that, because you really want such a thing to

Re: [Geoserver-devel] Questions about Dynamic Symbolizers

Michael Frumin ha scritto:
> It could also be a parameter in the SLD no?
Ouch please no, the less extras we add to SLD, the better, we're already
going far away from the standard enough. As a rule of thumb I'd like
to add extras to SLD only when there is no other clean way to get
a certain functionality.
If you notice with dynamic symbolizers I took care to at least keep
the SLD syntantically valid.
Cheers
Andrea
--
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------

Re: [Geoserver-devel] Questions about Dynamic Symbolizers

Andrea,
remember we talked about the implicancies of updating the external graphics
based on last modified time as you well described, but sort of agreed a good
comprimise solution would be to just update the cache on a config reload. We
could also set a global, fixed and configurable expiry time as to reduce the
amount of checks for modifications.
Cheers,
Gabriel
On Wednesday 31 December 2008 08:47:07 Andrea Aime wrote:

mfrumin ha scritto:

Hey all, check out my first experiment with this awesome new feature:
http://transit.frumin.net/subway/spark.php
but I have a couple of questions:
1. can this work fully vectorized? if my dynamic symbolizers were
vectors (SVG? PDF?) would it work? this way the whole thing can
be rendered as a nice PDF and printed on a large plotter to hang
on my wall...

Not at the moment, whatever the source form is, it gets rasterized
before entering the rendering pipeline. The reason is simple, it's a lot
faster.
It's possible to bring vector data up to the final rendering stages,
but it would require some changes in the rendering chain, and a
parameter to control that, because you really want such a thing to
happen only when printing (drawing SVG is very slow compared to just
blitting an image).

2. when you use dynamic symbolizers, what are the rules regarding
when it looks again at the external images? it's clear from my
access logs
that it has cached them somewhere

Yeah, this is a embarrassing as there is a static in memory cache
that does not check for source changes, so basically if you change
anything in your external images, you have to restart GeoServer.
I've been meaning to create a decent cache for a long time, but it's
definitely not trivial and thus requires sponsoring from some
organisation (or else me deciding to take a week of vacation to do it,
and then face in my spare time all regressions that may arise after the
change...). For example, for file system located data,
we'd have to do a last modification check, for stuff coming
from http we'd have to consider caching headers, and provide people
ways to override them since you cannot usually control remote server
behaviours. You'd also need to specify ways control how often
the expiry checks are made, since even just getting the last
modification date from a file is expensive under high concurrent
load .
For example, the security configuration files are under last
modification check so that if you modify their contents, GeoServer
picks up the modification. Well, I had to limit the check frequency
to once per second because otherwise it would have badly affected
scalability under high load.
Consider taking this approach to an http check for last modified
data (which may takes 100-1000 times more than a check on a file)
and you start appreciating how even just abiding to the http caching
standard is not ideal, we'd have to build limitations on top of it
too...
Cheers
Andrea

[Geoserver-devel] RE STconfig status and howto

I have got 1.7.x compiled and confirmed that RESTconfig is running.
Now I want to accomplish the following:
1. I have some postGIS tables that are listed as not yet configured.
I can see them listed under "Unconfigured FeatureTypes" when I on run a GET
to rest/folders/{folder}/layers.
In the only documentation I can find on
http://geoserver.org/display/GEOSDOC/RESTful+Configuration+API
It says that I can run a PUT or POST to configure a new layer into Geoserver
if I am going to POST, what kind of key-value pairs should be submitted ?
2. I have a shapefile set (zipped), how can I upload it and tell RESTconfig
to configure the shapefile as a Geoserver layer ?
I know there is a lot of effort spent on RESTconfig, but I don't find much
documents on how to use it.
If I figure out how to do the above, I will be happy to contribute something
to the Wiki.
Cheers.
Dukie
Raleigh, NC, USA
--
--
View this message in context: http://www.nabble.com/RESTconfig-status-and-howto-tp21284920p21284920.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.
------------------------------------------------------------------------------

Most versioning operations don't work anymore
---------------------------------------------
Key: GEOS-2543
URL: http://jira.codehaus.org/browse/GEOS-2543
Project: GeoServer
Issue Type: Bug
Components: Versioning
Reporter: Andrea Aime
Assignee: Andrea Aime
Fix For: 1.7.2
This is a result of fid validation patches, there is some code that does not properly build fids in the
versionin datastore, that did not cause issues as the lack of <featuretype> prefix in the fid was ignored,
up until the fix validation was installed in the jdbc datastores.
So the fix is to build proper fids in order to reinstate proper wfsv operation.
We also have to look into making sure the wfsv related tests are run during the geoserver/geotools builds on hudson
--
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.

Re: [Geoserver-devel] [Geoserver-users] RESTful geotiff uploading

This seems to have moved from a user support question to a design
discussion, so I'm moving to the developers' list.
As I recall, when we left the sprint last year, we were still undecided
on the structure of the configuration for 2.0. For GeoServer 2.0 we
would like to have multiple virtual servers hosted by the same GeoServer
instance. I am not sure we can reconcile this with the RESTConfig API
as exposed in GeoServer 1.7.x, although I imagine it will be as simple
as having a single hardcoded virtual server ID that is used and 405ing
all requests that manipulate the virtual servers themselves. One
question in particular that was left outstanding: Do we have multiple
sets of data/coverage stores, or do we make the virtual servers 'views'
into a single, flat collection of datasets? IIRC we were leaning toward
the latter.
I will draft a new proposal for the API and put it on the wiki sometime
soon, as there are some changes to be made even if we don't plan on
taking virtual servers into account. However, if we plan on changing
the configuration's structure for GeoServer 2.0, I think we would not be
serving users of the API very well to have the configuration API not
expose those changes, so we should probably not include a RESTConfig API
that doesn't at least separate 'publishing' from 'data configuration' in
the standard release. (I intuit that as long as we have that split, we
only differ from a reasonable API for virtual servers by a prefix or two.)
This has been a bit of a brain dump, so please let me know if any of
this was confusing.
David Winslow
Justin Deoliveira wrote:
> Yeah, I think all that is needed is to go over it once again and try to
> finalize an api. Up until now it has just been what David came up with
> (which is a great start), and some brainstorming at the sprint last year
> in Italy, and some with Tim and the javascript team. Add in to the mix a
> new configuration api its understandable that is not polished at this point.
>
> But good feedback. I hope this coming week to really go over whats there
> , improve the test coverage, and hopefully finalize an api in
> preparation to moving it to supported.
>
> -Justin
>
> Chris Holmes wrote:
>
>> Note that the REST API is far from set in stone, it's still a community
>> module, so this kind of feedback is great. If you'd like to propose a
>> scheme that's more restful that would be great, and we could likely
>> retool the module to follow that. Once we actually release it as part
>> of GeoServer it's going to be harder to change the API around, since
>> people will start to rely on it. But at this point no one has done a
>> full review, so thanks a bunch for the feedback.
>>
>> Chris
>>
>> Pete Schwamb wrote:
>>
>>> Yes, that helps explain things, although it seems to be a pretty
>>> significant departure from RESTful semantics.
>>>
>>> Thanks,
>>>
>>> -Pete
>>>
>>> On Jan 2, 2009, at 2:05 PM, David Winslow wrote:
>>>
>>>
>>>> Well, the folders/{folder}/layers/{layer}/url.{format} endpoint has
>>>> been
>>>> added since the last time I took a close look at the RESTConfig
>>>> module,
>>>> so I'm not 100% familiar with its usage. However, for looking up
>>>> coverage configurations in a GET request, the {folder} parameter is
>>>> interpreted as a "virtual folder." This is basically the name of the
>>>> directory for filesystem-backed data/coveragestores and the name of
>>>> the
>>>> datastore for others. For configuration of existing data/
>>>> coveragestores
>>>> you should use this convention. In this case specifically, you should
>>>> DELETE /rest/folders/data/layers/AutoPublish .
>>>>
>>>> I believe that the 'data' folder arose from the fact that the url
>>>> endpoint actually fetches the specified file and saves it in the data
>>>> directory, regardless of whether it's a local file or not. Simone
>>>> (cc'ed) would know more.
>>>>
>>>> Hope this helps,
>>>> David Winslow
>>>>
>>>> On Fri, 2009-01-02 at 12:57 -0600, Pete Schwamb wrote:
>>>>
>>>>> I spent some time figuring out how to upload geotiff coverages to
>>>>> geoserver using the RESTful config module, and was able to do so
>>>>> successfully, but I had some questions about the the organization of
>>>>> the resulting resources under /rest.
>>>>>
>>>>>
>>>>> I uploaded the tif using the url action like this:
>>>>>
>>>>>
>>>>> url -T sat_url.txt -v -XPUT --basic --user
>>>>> admin:geoserver http://localhost:8080/geoserver/rest/folders/AutoPublish/layers/SatIR/url.geotiff
>>>>>
>>>>>
>>>>> The sat_url.txt file had the following contents:
>>>>>
>>>>>
>>>>> file:/Users/pete/dev/geoserver-1.7.1/data_dir/coverages/SatData/
>>>>> Satellite_Image.tif
>>>>>
>>>>>
>>>>> Since I published to /rest/folders/AutoPublish/layers/SatIR/, I would
>>>>> expect to see a folder named AutoPublish, and a layer named SatIR,
>>>>> but
>>>>> instead I see the new resource
>>>>> at /rest/folders/data/layers/AutoPublish.
>>>>>
>>>>>
>>>>> Where did this folder called 'data' come from? Maybe I just don't
>>>>> understand the layout. I'd like to be able to programatically delete
>>>>> the layers, but I don't know what resource URI to delete. As far
>>>>> as I
>>>>> understand it, being RESTful means that I should be able to use the
>>>>> same URI to perform different operations on the same resource.
>>>>>
>>>>>
>>>>> -Pete
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Geoserver-users mailing list
>>>>> Geoserver-users@...
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Geoserver-users mailing list
>>> Geoserver-users@...
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>
>
>
>
------------------------------------------------------------------------------

Re: [Geoserver-devel] [Geoserver-users] RESTful geotiff uploading

Following up.
While the "virtual server" idea is dependent on whatever rest api we
finalize on I don't think it is a driver is it?
The way I sort of see things working is for 1.7.x we publish the "data"
part of the api, since as we all know there is currently no
data-publishing split. This means instead of dealing with layers and
folders we deal with feature types, datastores, etc...
Now when 2.0 comes around and we finally have the data-publishing split,
the "data" api will match pretty closely the 1.7.x api... perhaps a few
minor changes. Then we release the publishing api in addition to the
data api.
Or perhaps there should be only one api to rule them all... not sure. I
think this what tschaub wants to see, can't quite remember but I know he
had a strong opinion.
Anyways, a wiki page would be good that outlines a) where we are now and
b) where we want to go
2c,
-Justin
David Winslow wrote:
> This seems to have moved from a user support question to a design
> discussion, so I'm moving to the developers' list.
>
> As I recall, when we left the sprint last year, we were still undecided
> on the structure of the configuration for 2.0. For GeoServer 2.0 we
> would like to have multiple virtual servers hosted by the same GeoServer
> instance. I am not sure we can reconcile this with the RESTConfig API
> as exposed in GeoServer 1.7.x, although I imagine it will be as simple
> as having a single hardcoded virtual server ID that is used and 405ing
> all requests that manipulate the virtual servers themselves. One
> question in particular that was left outstanding: Do we have multiple
> sets of data/coverage stores, or do we make the virtual servers 'views'
> into a single, flat collection of datasets? IIRC we were leaning toward
> the latter.
>
> I will draft a new proposal for the API and put it on the wiki sometime
> soon, as there are some changes to be made even if we don't plan on
> taking virtual servers into account. However, if we plan on changing
> the configuration's structure for GeoServer 2.0, I think we would not be
> serving users of the API very well to have the configuration API not
> expose those changes, so we should probably not include a RESTConfig API
> that doesn't at least separate 'publishing' from 'data configuration' in
> the standard release. (I intuit that as long as we have that split, we
> only differ from a reasonable API for virtual servers by a prefix or two.)
>
> This has been a bit of a brain dump, so please let me know if any of
> this was confusing.
>
> David Winslow
>
> Justin Deoliveira wrote:
>> Yeah, I think all that is needed is to go over it once again and try
>> to finalize an api. Up until now it has just been what David came up
>> with (which is a great start), and some brainstorming at the sprint
>> last year in Italy, and some with Tim and the javascript team. Add in
>> to the mix a new configuration api its understandable that is not
>> polished at this point.
>>
>> But good feedback. I hope this coming week to really go over whats
>> there , improve the test coverage, and hopefully finalize an api in
>> preparation to moving it to supported.
>>
>> -Justin
>>
>> Chris Holmes wrote:
>>
>>> Note that the REST API is far from set in stone, it's still a
>>> community module, so this kind of feedback is great. If you'd like
>>> to propose a scheme that's more restful that would be great, and we
>>> could likely retool the module to follow that. Once we actually
>>> release it as part of GeoServer it's going to be harder to change the
>>> API around, since people will start to rely on it. But at this point
>>> no one has done a full review, so thanks a bunch for the feedback.
>>>
>>> Chris
>>>
>>> Pete Schwamb wrote:
>>>
>>>> Yes, that helps explain things, although it seems to be a pretty
>>>> significant departure from RESTful semantics.
>>>>
>>>> Thanks,
>>>>
>>>> -Pete
>>>>
>>>> On Jan 2, 2009, at 2:05 PM, David Winslow wrote:
>>>>
>>>>
>>>>> Well, the folders/{folder}/layers/{layer}/url.{format} endpoint
>>>>> has been
>>>>> added since the last time I took a close look at the RESTConfig
>>>>> module,
>>>>> so I'm not 100% familiar with its usage. However, for looking up
>>>>> coverage configurations in a GET request, the {folder} parameter is
>>>>> interpreted as a "virtual folder." This is basically the name of the
>>>>> directory for filesystem-backed data/coveragestores and the name
>>>>> of the
>>>>> datastore for others. For configuration of existing data/
>>>>> coveragestores
>>>>> you should use this convention. In this case specifically, you should
>>>>> DELETE /rest/folders/data/layers/AutoPublish .
>>>>>
>>>>> I believe that the 'data' folder arose from the fact that the url
>>>>> endpoint actually fetches the specified file and saves it in the data
>>>>> directory, regardless of whether it's a local file or not. Simone
>>>>> (cc'ed) would know more.
>>>>>
>>>>> Hope this helps,
>>>>> David Winslow
>>>>>
>>>>> On Fri, 2009-01-02 at 12:57 -0600, Pete Schwamb wrote:
>>>>>
>>>>>> I spent some time figuring out how to upload geotiff coverages to
>>>>>> geoserver using the RESTful config module, and was able to do so
>>>>>> successfully, but I had some questions about the the organization of
>>>>>> the resulting resources under /rest.
>>>>>>
>>>>>>
>>>>>> I uploaded the tif using the url action like this:
>>>>>>
>>>>>>
>>>>>> url -T sat_url.txt -v -XPUT --basic --user
>>>>>> admin:geoserver
>>>>>> http://localhost:8080/geoserver/rest/folders/AutoPublish/layers/SatIR/url.geotiff
>>>>>>
>>>>>>
>>>>>>
>>>>>> The sat_url.txt file had the following contents:
>>>>>>
>>>>>>
>>>>>> file:/Users/pete/dev/geoserver-1.7.1/data_dir/coverages/SatData/
>>>>>> Satellite_Image.tif
>>>>>>
>>>>>>
>>>>>> Since I published to /rest/folders/AutoPublish/layers/SatIR/, I would
>>>>>> expect to see a folder named AutoPublish, and a layer named
>>>>>> SatIR, but
>>>>>> instead I see the new resource
>>>>>> at /rest/folders/data/layers/AutoPublish.
>>>>>>
>>>>>>
>>>>>> Where did this folder called 'data' come from? Maybe I just don't
>>>>>> understand the layout. I'd like to be able to programatically delete
>>>>>> the layers, but I don't know what resource URI to delete. As far
>>>>>> as I
>>>>>> understand it, being RESTful means that I should be able to use the
>>>>>> same URI to perform different operations on the same resource.
>>>>>>
>>>>>>
>>>>>> -Pete
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Geoserver-users mailing list
>>>>>> Geoserver-users@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Geoserver-users mailing list
>>>> Geoserver-users@...
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>
>>
>>
>
--
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------