webb (JIRA | 2 Jan 13:59 2009

[Geoserver-devel] Created: (GEOS-2541) WFS not recognizing

WFS not recognizing 
--------------------

                 Key: GEOS-2541
                 URL: http://jira.codehaus.org/browse/GEOS-2541
             Project: GeoServer
          Issue Type: Bug
          Components: WFS
    Affects Versions: 1.7.1
         Environment: WinXP
            Reporter: webb
            Assignee: Andrea Aime
         Attachments: EDIT_WARD.xml

Hello:

I am getting this error while sending out an update request. I am also attaching my DescribeFeature XML for
this layer(From http://localhost:8080/geoserver/wfs?version=1.0.0&service=wfs&request=DescribeFeatureType&typename=topp:EDIT_WARD)

Request:

- <wfs:Transaction service="WFS" version="1.0.0" xmlns:ogc="http://www.opengis.net/ogc"
xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml"
xmlns:xls="http://niem.gov/niem/external/ogc-openls/1.1.0/dhs-gmo/1.0.0" xmlns:topp="http://www.openplans.org/topp">
- <wfs:Update typeName="EDIT_WARD">
- <wfs:Property>
  <wfs:Name>gml:GeometryAssociationType</wfs:Name> 
- <wfs:Value>
- <Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#26917" xmlns="gml">
- <outerBoundaryIs>
(Continue reading)

Gabriel Roldan | 2 Jan 20:22 2009

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
(Continue reading)

Andrea Aime | 2 Jan 20:39 2009

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.

------------------------------------------------------------------------------
Michael Frumin | 2 Jan 20:23 2009
Picon

Re: [Geoserver-devel] Questions about Dynamic Symbolizers

It could also be a parameter in the SLD no?

Gabriel Roldan wrote:
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 mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
webb (JIRA | 3 Jan 12:07 2009

[Geoserver-devel] Created: (GEOS-2542) org.geoserver.wfs.WFSTransactionException: topp:<TYPENAME> is read-only

org.geoserver.wfs.WFSTransactionException: topp:<TYPENAME> is read-only
-----------------------------------------------------------------------

                 Key: GEOS-2542
                 URL: http://jira.codehaus.org/browse/GEOS-2542
             Project: GeoServer
          Issue Type: Bug
          Components: WFS
    Affects Versions: 1.7.1
         Environment: Win XP
            Reporter: webb
            Assignee: Andrea Aime
         Attachments: EDIT_WARD.xml

Hi,

Thanks for your response to my query for GEOS: 2541. I was able to proceed but then got struck. It is giving me
the error the layer is read_Only. I am also attaching the DescribeFeatureType xml as before. 

I am sure I am defining my indexes properly in the table: 

select sdo_index_name, sdo_index_owner, sdo_layer_gtype, sdo_root_mbr from
user_sdo_index_metadata where sdo_index_name='IDX_EDITWARD_GEOM'

IDX_EDITWARD_GEOM	ORMS	MULTIPOLYGON	MDSYS.SDO_GEOMETRY(2003,null,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(534583.028923,4800227.837578,552019.43065,4817244.301605))

Additionally, I am using the default security settings:
*.*.r=*
*.*.w=*

Request:

"<wfs:Transaction service=\"WFS\" version=\"1.0.0\" xmlns:ogc=\"http://www.opengis.net/ogc\"
xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\"
xmlns:xls=\"http://niem.gov/niem/external/ogc-openls/1.1.0/dhs-gmo/1.0.0\" xmlns:topp=\"http://www.openplans.org/topp\">
<wfs:Update typeName=\"EDIT_WARD\">
<wfs:Property><wfs:Name>GEOM</wfs:Name><wfs:Value>
<MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#26917\"
xmlns=\"gml\"><PolygonMember><Polygon><outerBoundaryIs><LinearRing><coordinates
decimal=\".\" cs=\",\" ts=\" \">533525,4809587,0 533961,4809866,0 534910,4810123,0
535334,4810279,0 535681,4810491,0 535960,4810648,0 536228,4810782,0 536295,4810871,0
536641,4811027,0 536920,4811184,0 537333,4811373,0 537579,4811608,0 537858,4811831,0
538070,4811898,0 538327,4811932,0 538751,4811753,0 539042,4811407,0 539243,4811496,0
539365,4811474,0 539511,4811284,0 540248,4811061,0 540694,4811217,0 540839,4811519,0
541018,4811675,0 541230,4811854,0 537958,4813651,0 537166,4814042,0 536775,4813808,0
536418,4813618,0 536183,4813528,0 535323,4812903,0 535323,4812747,0 534687,4812512,0
534765,4812088,0 532487,4811139,0 533525,4809587,0</coo
 rdinates>
</LinearRing>
</outerBoundaryIs>
</Polygon></PolygonMember></MultiPolygon>
</wfs:Value>
</wfs:Property>
<Filter xmlns=\"ogc\">
<PropertyIsEqualTo>
<PropertyName>topp:WARDID</PropertyName><Literal>26</Literal></PropertyIsEqualTo>
</Filter>
</wfs:Update>
</wfs:Transaction>"

Response:

"<wfs:Transaction service=\"WFS\" version=\"1.0.0\" xmlns:ogc=\"http://www.opengis.net/ogc\"
xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\"
xmlns:xls=\"http://niem.gov/niem/external/ogc-openls/1.1.0/dhs-gmo/1.0.0\"
xmlns:topp=\"http://www.openplans.org/topp\"><wfs:Update
typeName=\"EDIT_WARD\"><wfs:Property><wfs:Name>GEOM</wfs:Name><wfs:Value><MultiPolygon
srsName=\"http://www.opengis.net/gml/srs/epsg.xml#26917\"
xmlns=\"gml\"><PolygonMember><Polygon><outerBoundaryIs><LinearRing><coordinates
decimal=\".\" cs=\",\" ts=\" \">533525,4809587,0 533961,4809866,0 534910,4810123,0
535334,4810279,0 535681,4810491,0 535960,4810648,0 536228,4810782,0 536295,4810871,0
536641,4811027,0 536920,4811184,0 537333,4811373,0 537579,4811608,0 537858,4811831,0 538070,4811898,
 0 538327,4811932,0 538751,4811753,0 539042,4811407,0 539243,4811496,0 539365,4811474,0
539511,4811284,0 540248,4811061,0 540694,4811217,0 540839,4811519,0 541018,4811675,0
541230,4811854,0 537958,4813651,0 537166,4814042,0 536775,4813808,0 536418,4813618,0
536183,4813528,0 535323,4812903,0 535323,4812747,0 534687,4812512,0 534765,4812088,0
532487,4811139,0
533525,4809587,0</coordinates></LinearRing></outerBoundaryIs></Polygon></PolygonMember></MultiPolygon></wfs:Value></wfs:Property><Filter xmlns=\"ogc\"><PropertyIsEqualTo><PropertyName>topp:WARDID</PropertyName><Literal>26</Literal></PropertyIsEqualTo></Filter></wfs:Update></wfs:Transaction>"

--

-- 
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

------------------------------------------------------------------------------
dukie | 5 Jan 04:25 2009
Picon

[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.

------------------------------------------------------------------------------
Andrea Aime (JIRA | 5 Jan 13:25 2009

[Geoserver-devel] Created: (GEOS-2543) Most versioning operations don't work anymore

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

------------------------------------------------------------------------------
Deleuze S├ębastien | 5 Jan 13:49 2009

Re: [Geoserver-devel] Start up problem with geoserver 1.7.1a

Hi,

 

This issue has been solved by removing some libs from shared and common/endorsed libs of the tomcat install directory.

 

Regards,

Sébastien Deleuze

 

De : Masciotra Arnaud [mailto:Arnaud.Masciotra-kcH4OoMoNbE4Q++5jOxPmw@public.gmane.org]
Envoyé : mardi 30 décembre 2008 12:11
À : geoserver-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org
Objet : [GGP2-IGN] Start up problem with geoserver 1.7.1a

 

Hello,

 

I tried to launch the geoserver 1.7.1a (the war version) with tomcat 5.5.23 and Java 1.50_14.

 

But I always got the same errors (the full stack trace is attached) :

 

30 déc. 11:40:09 ERROR [context.ContextLoader] - Context initialization failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'applicationState' defined in URL [file:/D:/workspace/PSEM/geoserver-psem/target/webapp/WEB-INF/classes/applicationContext.xml]: Cannot resolve reference to bean 'data' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'data' defined in URL [jar:file:/D:/workspace/PSEM/geoserver-psem/target/webapp/WEB-INF/lib/main-1.7.1.jar!/applicationContext.xml]: Cannot resolve reference to bean 'geoServer2' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'geoServer2' defined in URL [jar:file:/D:/workspace/PSEM/geoserver-psem/target/webapp/WEB-INF/lib/main-1.7.1.jar!/applicationContext.xml]: Initialization of bean failed; nested exception is java.lang.NoSuchMethodError: org.w3c.dom.Node.getTextContent()Ljava/lang/String;

 

I used a war exploded version with no modifications and I removed all the styles and layers (I got same errors with the defaults SLD and Layers)

 

I already removed xercesImpl.jar, xalan.jar, and xml-api.jar with no changes.

 

Do you have a solution for my problem ?

 

Thanks,

 

Arnaud Masciotra

Atos Worldline

Public Santé Transport

Tel : +33 4 78 17 87 44 - Fax : +33 4 78 17 87 78

arnaud.masciotra <at> atosorigin.com

 

http://www.atosorigin.com - http://www.atosworldline.com

Atos Worldline is an Atos Origin company

 


Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

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.



Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

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.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
David Winslow | 5 Jan 16:19 2009

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
>>>       
>
>
>   

------------------------------------------------------------------------------
Justin Deoliveira | 5 Jan 16:47 2009

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.

------------------------------------------------------------------------------

Gmane