Arne Kepp wrote:
> Andrea Aime wrote:
>> David Winslow ha scritto:
>>
>>> Hello all,
>>>
>>> Arne and I are working on a new RESTful configuration API for geoserver
>>> datastores and featuretypes. We've added a page to the wiki at
>>> http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please
>>> take a look and let us know of any concerns or questions you may have.
>>>
>> I've read the proposal, looks good. Some considerations:
>> * there is no specification on the resource representation. As Justin
>> said elsewhere, the content of the resource really depends on what
>> the actual configuration is supposed to look like, so it's bound
>> to change when we change the the config subsystem, and every time
>> we change the configuration options as well.
>> I would also like to point out the current feature type
>> config is not made only of info.xml, but may also contain another file
>> for an overridden feature type schema, see the citewfs-1.1
>> configuration for an example (it's just a type override, does not
>> really remodels the schema).
>>
> Thanks, and yes, we're very open to suggestions on how the feature
> should be described. As a first approximation we intended to mimic the
> configuration files, but we'll be happy to change that if people come up
> with suggestions.
The other thing we have in there, that people may want pretty soon, is
the templates for KML description and time stuff.
Though it's overkill for now, I wonder if eventually we might want the
concept of a 'parent' feature type that things could inherit from, like
it'd use their metadata and kml templates and the like.
>> * for feature types configuration it seems from the api you have to
>> "put" the info.xml file into the right path. So how do you know
>> what are the avaialble feature types? Maybe it's better to list
>> all of them and have a "active" flag to differentiate those that
>> are actually configured, or have a separate path that lists all
>> available feature types (and their structure), something like:
>> /api/datastore/{datastore}/availablefeaturetype/
>> /api/datastore/{datastore}/configuredfeaturetype/
>> (don't like the name but you get the idea)
>>
> If you go to api/datastore/{datastore} you should see a list of links to
> information associated with the datastore, and if you click the link to
> api/datastore/{datastore}/featuretype you see a list of the feature
> types. I am not sure whether we should offer additional views based on
> namespaces. These pages are rendered in XHTML, so that it can easily be
> inspected with a normal browser. However, we haven't considered the
> distinction between active and available feature types, so we need to
> learn more about that.
Yeah, this distinction was one of the things I was thinking about as
well. So right now, by default in the UI, if you configure a datastore
none of its featureTypes are published. You have to go to the
featureType page and make a default style, get the SRS and bounds. And
hopefully you also fill out other metadata, like actual information
about the data - abstract, keywords, ect, that crawlers can use and
search on.
As for a separate path vs a flag, I think it depends on if 'active' is
just a property, or if it's a different resources.
One way to handle it, which hits on something that I'd like to see, is a
resource that's just:
/api/data/
And it would list all the configured featureTypes and Coverages. Though
perhaps we should wait until we get the AtomPub implementation, since
that should also have the ability to list such things, and then to get
at the actual data.
So I'm leaning to just having an 'active' flag. I think it'd also be
helpful to be able to create a new datastore and have it by default make
all its feature types active (or at least all that it could). Perhaps
at that step we could make the user supply metadata that they'd all
inherit. But in general we can derive enough automatically in most
cases that we shouldn't need to require doing lots of stuff to activate.
In turn if a featureType is missing a CRS or has something that really
does prevent us from activating it we should have the REST interface
reject turning it active unless they configure it.
>> * there is no mention of coverages over there?
>>
> That will come very soon, we omitted them so that people could start
> discussing our proposal, but it will be there from the start.
>> * style editing is ok, but I think it could be a bit more ambitious
>> to support editing from javascript clients. You know, stuff like
>> exposing the structure of a style as a tree and have each part
>> be modifiable at will. As far as I remember Andrea Cappugi was
>> looking for something like this.
>>
> I am not sure this makes sense, or maybe the SLD files I wrote were just
> poor. It seems to me that in many case you will want to modify every
> branch of the SLD? Like when you change the color of a feature, you
> probably want this to happen at every resolution.
I'd like to see what code he came up with. For now I think it'll be a
big win just to be able to put and get styles.
One question that wasn't clear from the api - is listing and putting
styles based on their filename? Or the actual 'name' of the SLD? Or an
arbitrary name? I guess the current thing is an arbitrary name, but it
should be noted that SLD's have a 'name' parameter.
I suppose now's not the time to rearrange the messy styling backend.
But I think what I might recommend is to also allow a post to api/style/
that then derives the name of the style from the 'name' portion of the SLD.
One last question - singular vs. plural for lists?
I was thinking it'd be /api/datastores/ and /api/styles/ instead of
/api/datastore/ and /api/style/ Thoughts?
But yeah, this is looking quite nice, I'm excited.
Chris

Hi Andrea,
I've tried both line and polygon geometry with the same result. I can
manually build the SLD in the Style editor and then apply that style within
the FeatureType editor. That's my current workaround.
Thanks, Bob
aaime wrote:
>
> Bob Nutsch ha scritto:
>> Hi,
>>
>> I'm wondering if I should be able to create a new SLD for an ArcSDE
>> FeatureType by clicking on the 'Create new SLD' when editing an ArcSDE
>> FeatureType? When clicking on the 'Create new SLD' button, I see the
>> 'Apply
>> Style' and 'Finished' buttons, and a box area below that shows some basic
>> info about the data, but not the information that I see when working with
>> a
>> shapefile.
>>
>> When I click on 'Create new SLD' for shapefile data, I see a bluish box
>> above the 'Apply Style' button that allows me to set the label and
>> colors.
>>
>> If this is a bug, I can log it.
>
> Bob,
> that page is not really that solid and sometimes it just does not
> work... we hoped to replace it with a better one but so far nothing
> happened.
>
> Is it possible that the page does not work because your feature type
> geometry is generic, that is, not a point or a line, but "abstract
> geometry" instead? I don't have SDE so I don't know if that might happen
> or not (and I don't know what to do about it either if this happen...)
>
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
View this message in context: http://www.nabble.com/Cannot-create-new-SLD-for-ArcSDE-FeatureType-tf4725606.html#a13511523
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Bob Nutsch ha scritto:
> Hi,
>
> I'm wondering if I should be able to create a new SLD for an ArcSDE
> FeatureType by clicking on the 'Create new SLD' when editing an ArcSDE
> FeatureType? When clicking on the 'Create new SLD' button, I see the 'Apply
> Style' and 'Finished' buttons, and a box area below that shows some basic
> info about the data, but not the information that I see when working with a
> shapefile.
>
> When I click on 'Create new SLD' for shapefile data, I see a bluish box
> above the 'Apply Style' button that allows me to set the label and colors.
>
> If this is a bug, I can log it.
Bob,
that page is not really that solid and sometimes it just does not
work... we hoped to replace it with a better one but so far nothing
happened.
Is it possible that the page does not work because your feature type
geometry is generic, that is, not a point or a line, but "abstract
geometry" instead? I don't have SDE so I don't know if that might happen
or not (and I don't know what to do about it either if this happen...)
Cheers
Andrea

Hi,
I'm wondering if I should be able to create a new SLD for an ArcSDE
FeatureType by clicking on the 'Create new SLD' when editing an ArcSDE
FeatureType? When clicking on the 'Create new SLD' button, I see the 'Apply
Style' and 'Finished' buttons, and a box area below that shows some basic
info about the data, but not the information that I see when working with a
shapefile.
When I click on 'Create new SLD' for shapefile data, I see a bluish box
above the 'Apply Style' button that allows me to set the label and colors.
If this is a bug, I can log it.
Thanks, Bob
--
View this message in context: http://www.nabble.com/Cannot-create-new-SLD-for-ArcSDE-FeatureType-tf4725606.html#a13511202
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Hi Justin,
before you go away for vacation I'd like to hear your opinion
on the group of issues I've opened against the axis order stuff.
About http://jira.codehaus.org/browse/GEOS-1440, it seems to me
the actual GML3 type bindings do not have the same CRS inheritance stuff
we added in AbstractGeometryTypeBinding. Which makes me wonder a
little... AbstractGeometryTypeBinding is in GML3, but nothing inherits
from it, MultiSurfaceTypeBinding for example does not have the CRS
inheritance and extends AbstractComplexBinding... isn't this strange?
Where is the missing link?
In issues like GEOS-1439, GEOS-1435 and GEOS-1437 we have the problem of
jumping between srs names and CoordinateReferneceSystem objects because
the Envelope binding parses the srs into a CoordinateReferenceSystem
object, but in order to build a bbox filter we need the srs back.
I guess we should use GML3EncodingUtils.crs(CRS), but modify it
so that it returns "urn:xxx" or "epsg:xxxx" depending on the actual
axis order. What do you think?
Issues like GEOS-1441 and GEOS-1436
raise the point of knowing what is the
declared CRS. In WFS 1.0 we do declare EPSG:4326, in 1.1
urn:x-ogc:def:crs:EPSG:6.11.2:4326 so the axis order is swapped.
What is needed is an utility allowing to know how a particular
internal crs has been declared to the outside world.
Where do we place such an utility method?
I was thinking the WFS class, but it's mostly configuration.
Anyways, GEOS-1441 is about encoding, so that method should
be visible on the GetFeature class, whilst 1436 is about parsing,
and there I guess we should grab the declared crs as soon as
we know the feature type and inject it in the parsing context,
so utility should be visible from QueryTypeBinding (the only
binding that gets to see the typeName).
Cheers
Andrea

Hi Justin,
I uploaded a screenshot that shows the information as I had it just before
clicking the Submit-Apply-Save buttons. The info.xml is the file as it
exists after using Submit-Apply-Save.
I spent a bit of time on this and discovered:
a) when creating a *new* FeatureType, specifying an SRS of 2266 and
selecting the 'Reproject from native to declared SRS' the 2266 min-max
values are correctly stored in the info.xml
b) when editing an *existing* FeatureType and changing the SRS to something
different, those changes are *not* stored in the info.xml but yet the map
displayed via the Demo tool reflects the new projection (only if fully
zoomed out, I cannot zoom in else the map disappears). I'm really confused
now. :-)
c) I ran my tests with both shapefiles and SDE data and both behaved the
same except for the shapefile. In that scenario, when trying to display the
shapefile in stateplane using the built-in Demo tool, no map appeared in the
OpenLayers map preview even when fully zoomed out.
Thanks for the help.
Bob
http://www.nabble.com/file/p13510981/srsnd.gifhttp://www.nabble.com/file/p13510981/info.xml info.xml
Justin Deoliveira-4 wrote:
>
> Strange... I am not sure if i can quite understanding the issue you are
> having. When I try to replicate using a shapefile just in lat long and
> set the same option to reproject on the fly to a projected coordinate
> system (3005) it seems to work ok.
>
> Bob, could you perhaps do the following:
>
> * include a couple of screen shots of the feature type editor page
> * include the info.xml that gets saved out
>
> That might help us get on the same page a bit better.
>
> Thanks,
>
> -Justin
>
> Nutsch, Bob D. wrote:
>> Thanks Justin for the info.
>>
>> I should have mentioned in my earlier post that after seeing the
>> correctly calculated extents within the GUI, then clicking Submit,
>> Apply, Save, when I go back to the FeatureType editor, those calculated
>> extents are gone, replaced by the original lat-long extents. So I don't
>> think that this tool is working like it should. Unless some other spec
>> file is storing this information for later retrieval by some other part
>> of GeoServer.
>>
>> I did discover that I can manually edit the info.xml, restart Tomcat,
>> and then display my data in state plane. However, there are some
>> issues, since I have to zoom completely out (I'm using the built-in
>> openlayers from the Demo interface) to see the map, and if I zoom in at
>> all, the map disappears. When viewing the map, I cannot click on a
>> feature to get it's attributes. I can click a feature, but no attributes
>> are displayed. It's as if the mouse click location is not being
>> re-projected.
>>
>> So, maybe I'm mis-understanding the utility of the SRS stuff in the GUI.
>> The 'Reproject from native to declared SRS' suggests to me that it
>> should project on the fly, making the image from that WMS appear in that
>> projection on a client. But perhaps it's something along the lines as
>> you suggest, not sure.
>>
>> Thanks again, Bob
>>
>>
>>> -----Original Message-----
>>> From: Justin Deoliveira [mailto:jdeolive@...]
>>> Sent: Tuesday, October 30, 2007 2:54 PM
>>> To: Nutsch, Bob D.
>>> Cc: geoserver-devel@...
>>> Subject: Re: [Geoserver-devel] Problem with on the fly projection
>>>
>>> I could be wrong but I believe this is the intended behavior.
>>> When you select that srs handling option all it does it tell
>>> GeoServer to reproject whenever outputting.. so I would exect
>>> the state plane bounds to be what shows up in say a
>>> capabilities document... but see no reason why info.xml
>>> should not store the native bounds.
>>>
>>> Andrea can give you a more decisive answer.
>>>
>>> -Justin
>>>
>>> Bob Nutsch wrote:
>>>> Hi,
>>>>
>>>> For both shapefiles and SDE vector data I am having a
>>> problem with on
>>>> the fly projection when using 1.6 Beta 4, running in Tomcat
>>> 5.5, XP,
>>>> Java 1.5.0_13.
>>>>
>>>> The native format of the data is geographic, NAD83. I'm trying to
>>>> project to EPSG 2266 (state plane). In the FeatureType Editor, I
>>>> enter the 2266 in the SRS field, and from the SRS Handling
>>> pull-down
>>>> menu I select 'Reproject from native to declared SRS'. I
>>> then click
>>>> on the Generate button and I then see the min-max X-Y's correctly
>>>> calculated from the data extent. I scroll down and click on the
>>>> Submit button then Apply and Save. However, in the
>>> info.xml for that
>>>> layer, the min-max values remain unchanged, they still
>>> reflect lat-long and not state plane.
>>>> Am I missing something or is this a feature?
>>>>
>>>> Thanks, Bob
>>>>
>>>>
>>>>
>>>
>>> --
>>> Justin Deoliveira
>>> The Open Planning Project
>>> http://topp.openplans.org
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@...
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>> !DSPAM:4007,47279dfc112642458217002!
>>
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> http://topp.openplans.org
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
View this message in context: http://www.nabble.com/Problem-with-on-the-fly-projection-tf4720367.html#a13510981
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

this one is because I've updated 1.5.x to point to geotools 2.3.6-SNAPSHOT so
for those of us working on it, it does not screw up with the geoserver 1.5.4
release. Yet the geotools 2.3.6-SNAPSHOT jars did not finished being uploaded
to the repository.
Gabriel
On Wednesday 31 October 2007 03:01:12 am Continuum wrote:
> http://traffic.openplans.org:8080/continuum/buildResult.action?buildId=172&amp;
>projectId=8
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi,
Can you tell us more about "said classes"? What function are they
performing? Where do they live? Are they running inside of GeoServer? or
part of the front end of the web application? At some other middle tier?
etc...
Also, do you have any specific requirement to run GeoServer inside of
tomcat? For deployment time its definitely recemmended but for
developing and running from within Eclipse I would recommend jetty. Some
docs about setting that up can be found here:
http://docs.codehaus.org/display/GEOSDOC/3+Eclipse+Quickstart
As for front end stuff... You should take a look at the OpenLayers
library. Its a logical starting point for any web application that needs
to embed a map in the application. You can find more info on the
openlayers wiki, and if you like what you see check out the examples
that ship with openlayers, they are a great source of info.
jkb wrote:
> Hi,
>
> I want to develop a web application with Geoserver, and being new to
> the program I was hoping some of you could point me in the right
> direction to start off from. What I would like to do is:
>
> - develop Geoserver in Eclipse w/ Tomcat (OS X 10.5)
>
> - capture a point on mouse click and pass the coordinates to java
> classes already in place
>
> - render new features / update displayed features on the basis of
> actions performed in said classes (which already successfully query a
> PostGIS layer)
>
> Assuming I can get the Eclipse / Tomcat setup working*, are there any
> code samples / online resources available (or just plain old advice!)
> to help me start off on these last two points?
>
> Any assistance gratefully received,
>
> Jim
>
> *I've seen some of the docs on the website referring to setting up an
> Eclipse / tomcat install on OS X but I gather I'll have to tinker with
> this somewhat unless there are more detailed instructions I'm unaware
> of...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4007,4727a85d137868992556831!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Strange... I am not sure if i can quite understanding the issue you are
having. When I try to replicate using a shapefile just in lat long and
set the same option to reproject on the fly to a projected coordinate
system (3005) it seems to work ok.
Bob, could you perhaps do the following:
* include a couple of screen shots of the feature type editor page
* include the info.xml that gets saved out
That might help us get on the same page a bit better.
Thanks,
-Justin
Nutsch, Bob D. wrote:
> Thanks Justin for the info.
>
> I should have mentioned in my earlier post that after seeing the
> correctly calculated extents within the GUI, then clicking Submit,
> Apply, Save, when I go back to the FeatureType editor, those calculated
> extents are gone, replaced by the original lat-long extents. So I don't
> think that this tool is working like it should. Unless some other spec
> file is storing this information for later retrieval by some other part
> of GeoServer.
>
> I did discover that I can manually edit the info.xml, restart Tomcat,
> and then display my data in state plane. However, there are some
> issues, since I have to zoom completely out (I'm using the built-in
> openlayers from the Demo interface) to see the map, and if I zoom in at
> all, the map disappears. When viewing the map, I cannot click on a
> feature to get it's attributes. I can click a feature, but no attributes
> are displayed. It's as if the mouse click location is not being
> re-projected.
>
> So, maybe I'm mis-understanding the utility of the SRS stuff in the GUI.
> The 'Reproject from native to declared SRS' suggests to me that it
> should project on the fly, making the image from that WMS appear in that
> projection on a client. But perhaps it's something along the lines as
> you suggest, not sure.
>
> Thanks again, Bob
>
>
>> -----Original Message-----
>> From: Justin Deoliveira [mailto:jdeolive@...]
>> Sent: Tuesday, October 30, 2007 2:54 PM
>> To: Nutsch, Bob D.
>> Cc: geoserver-devel@...
>> Subject: Re: [Geoserver-devel] Problem with on the fly projection
>>
>> I could be wrong but I believe this is the intended behavior.
>> When you select that srs handling option all it does it tell
>> GeoServer to reproject whenever outputting.. so I would exect
>> the state plane bounds to be what shows up in say a
>> capabilities document... but see no reason why info.xml
>> should not store the native bounds.
>>
>> Andrea can give you a more decisive answer.
>>
>> -Justin
>>
>> Bob Nutsch wrote:
>>> Hi,
>>>
>>> For both shapefiles and SDE vector data I am having a
>> problem with on
>>> the fly projection when using 1.6 Beta 4, running in Tomcat
>> 5.5, XP,
>>> Java 1.5.0_13.
>>>
>>> The native format of the data is geographic, NAD83. I'm trying to
>>> project to EPSG 2266 (state plane). In the FeatureType Editor, I
>>> enter the 2266 in the SRS field, and from the SRS Handling
>> pull-down
>>> menu I select 'Reproject from native to declared SRS'. I
>> then click
>>> on the Generate button and I then see the min-max X-Y's correctly
>>> calculated from the data extent. I scroll down and click on the
>>> Submit button then Apply and Save. However, in the
>> info.xml for that
>>> layer, the min-max values remain unchanged, they still
>> reflect lat-long and not state plane.
>>> Am I missing something or is this a feature?
>>>
>>> Thanks, Bob
>>>
>>>
>>>
>>
>> --
>> Justin Deoliveira
>> The Open Planning Project
>> http://topp.openplans.org
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4007,47279dfc112642458217002!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

There is no real objection to this, except that it's a "hard"
cut-and-paste problem to go and re-do every logging statement in every
class everywhere.
Once Andrea and Martin decided to go directly with log4j (or
whatever...they just picked log4j because it made sense to them) they
decided that the EASY way to get every class everywhere using log4j (or
whatever) was to use a syntactic change like so:
OLD CODE: Logger _logger =
java.util.logging.Logger.getLogger("classname");
NEW CODE: Logger _logger =
org.geotools.util.Logging.getLogger("classname");
This was deemed (rightly in my eyes!) as an easier change to make across
the entire geotools codebase, and an easy one to document and implement.
Now what would this org.geotools.util.Logging.getLogger(String) method
return?
Well, it would return a subclass of "java.util.logger.Logger" that just
straight redirects EVERYTHING to log4j (or slf4j or whatever). It would
just call straight through, mapping all the relevant calls including the
EXTREMELY important "isLoggable()" call, right through to whatever the
underlying logging mechanism is.
This way we don't have to do an enormous amount of re-coding inside
geotools, all the code stays largely the same, and the end result is
almost exactly the same.
The added bonus is that we can make the
"org.geotools.util.Logging.getLogger(string)" method return various
different Logger subclasses. It could return a Logger that sends
everything straight through to log4j. It could return a Logger that
sends everything straight through to slf4j. It could return a logger
that sends everything straight through to Eclipse RCP trace events.
Etc.
Here's the short recap:
1) java.util.logging.* has a VERY rich interface for supporting lots of
log-related things like i18n, resourcebundles and stack traces.
2) No other logging framework has everything that java.util.logging.*
has (probably for a good reason!)
3...and this one's the clincher) Geotools USES lots of the stuff from 1
(like all of Martin's code).
The specific wins of Andreas and Martin's proposal is this:
* Dumping 1 and going to 2 is a painful CODING process. Not just a
cut-n-paste (in my opinion) or a sed/awk experience.
* Andrea and Martin's solution is simply an acceptance of the fact that
lots of Geotools code uses java.util.logging.* classes, and it would be
a lot of grunt search-and-replace to fix it. We've got enough grunt
search-and-replace(-and-test) coding on our plates already (filters,
featuremodel, geoapi, gce).
In the end I think the biggest concern is about hacks. Is subclassing
java.util.logging.Logger in this way a hack?
I'd say that with the clean redirect to a backend logging system, it
isn't any more of a hack than any other configurable logging facade
system (log4j, slf4j, commons-logging, etc). They're all just facade
systems that run to a back-end logger. We've picked a facade, it's all
in the code, now let's stick to it.
See you all in the GS IRC meeting!
--saul
On Tue, 2007-10-30 at 14:17 -0400, Chris Holmes wrote:
> Ok, I'm trying to get a handle on this issue.
>
> One question, what's the objection to just using SFL4J ?
>
> It seems to meet Justin's criteria of using a standard library, it'll
> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot better
> than commons logging.
>
> I imagine I just missed what the objection was, but I'm curious to hear it.
>
> Chris
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________ Geotools-devel mailing list Geotools-devel@... https://lists.sourceforge.net/lists/listinfo/geotools-devel

Hi,
I want to develop a web application with Geoserver, and being new to
the program I was hoping some of you could point me in the right
direction to start off from. What I would like to do is:
- develop Geoserver in Eclipse w/ Tomcat (OS X 10.5)
- capture a point on mouse click and pass the coordinates to java
classes already in place
- render new features / update displayed features on the basis of
actions performed in said classes (which already successfully query a
PostGIS layer)
Assuming I can get the Eclipse / Tomcat setup working*, are there any
code samples / online resources available (or just plain old advice!)
to help me start off on these last two points?
Any assistance gratefully received,
Jim
*I've seen some of the docs on the website referring to setting up an
Eclipse / tomcat install on OS X but I gather I'll have to tinker with
this somewhat unless there are more detailed instructions I'm unaware
of...

I really think this conversation needs to move to the IRC meeting.
There are LOTS of things to say, and I can't send my emails fast enough
to keep up with the changing discussion.
3:00. Be there or be square!
--saul
On Tue, 2007-10-30 at 14:30 -0400, Chris Holmes wrote:
>
> Andrea Aime wrote:
> > Chris Holmes ha scritto:
> >> Ok, I'm trying to get a handle on this issue.
> >>
> >> One question, what's the objection to just using SFL4J ?
> >>
> >> It seems to meet Justin's criteria of using a standard library, it'll
> >> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot
> >> better than commons logging.
> >>
> >> I imagine I just missed what the objection was, but I'm curious to
> >> hear it.
> >
> > sfl4j is just a facade like commons logging. Now, in Jetty by default
> > they put an implementation of the library that redirects to "simple
> > logging". Given that it's the first element in the classpath it'll
> > override whatever implementation we put in our library, meaning that
> > we would not be able to force log4j usage unless we manually change
> > the jars in the Jetty container (remember, slf4j way of doing
> > redirections is to implement exactly the same classes in the different
> > jars and have classloading decide which one gets used).
> But GeoServer isn't relying on any log4g usage, right? Why would we
> want to force it?
>
> >
> > I guess the second problem is timing, the slf4j is different enough
> > from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
> > manual changes will have to be performed manually instead of using
> > a single search and replace, especially in the modules managed
> > by Martin.
> >
> Hmmm... Let's see what he says.
> What about GeoServer using sfl4j and geotools continue to use java
> logging? Would that help solve things?
>
> Chris
>
> > Cheers
> > Andrea
> >
> > !DSPAM:4005,472776d522262143011171!
> >
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Thanks Justin for the info.
I should have mentioned in my earlier post that after seeing the
correctly calculated extents within the GUI, then clicking Submit,
Apply, Save, when I go back to the FeatureType editor, those calculated
extents are gone, replaced by the original lat-long extents. So I don't
think that this tool is working like it should. Unless some other spec
file is storing this information for later retrieval by some other part
of GeoServer.
I did discover that I can manually edit the info.xml, restart Tomcat,
and then display my data in state plane. However, there are some
issues, since I have to zoom completely out (I'm using the built-in
openlayers from the Demo interface) to see the map, and if I zoom in at
all, the map disappears. When viewing the map, I cannot click on a
feature to get it's attributes. I can click a feature, but no attributes
are displayed. It's as if the mouse click location is not being
re-projected.
So, maybe I'm mis-understanding the utility of the SRS stuff in the GUI.
The 'Reproject from native to declared SRS' suggests to me that it
should project on the fly, making the image from that WMS appear in that
projection on a client. But perhaps it's something along the lines as
you suggest, not sure.
Thanks again, Bob
=20
> -----Original Message-----
> From: Justin Deoliveira [mailto:jdeolive@...]=20
> Sent: Tuesday, October 30, 2007 2:54 PM
> To: Nutsch, Bob D.
> Cc: geoserver-devel@...
> Subject: Re: [Geoserver-devel] Problem with on the fly projection
>=20
> I could be wrong but I believe this is the intended behavior.=20
> When you select that srs handling option all it does it tell=20
> GeoServer to reproject whenever outputting.. so I would exect=20
> the state plane bounds to be what shows up in say a=20
> capabilities document... but see no reason why info.xml=20
> should not store the native bounds.
>=20
> Andrea can give you a more decisive answer.
>=20
> -Justin
>=20
> Bob Nutsch wrote:
> > Hi,
> >=20
> > For both shapefiles and SDE vector data I am having a=20
> problem with on=20
> > the fly projection when using 1.6 Beta 4, running in Tomcat=20
> 5.5, XP,=20
> > Java 1.5.0_13.
> >=20
> > The native format of the data is geographic, NAD83. I'm trying to=20
> > project to EPSG 2266 (state plane). In the FeatureType Editor, I=20
> > enter the 2266 in the SRS field, and from the SRS Handling=20
> pull-down=20
> > menu I select 'Reproject from native to declared SRS'. I=20
> then click=20
> > on the Generate button and I then see the min-max X-Y's correctly=20
> > calculated from the data extent. I scroll down and click on the=20
> > Submit button then Apply and Save. However, in the=20
> info.xml for that=20
> > layer, the min-max values remain unchanged, they still=20
> reflect lat-long and not state plane.
> >=20
> > Am I missing something or is this a feature?
> >=20
> > Thanks, Bob
> >=20
> >=20
> >=20
>=20
>=20
> --
> Justin Deoliveira
> The Open Planning Project
> http://topp.openplans.org
>=20

I could be wrong but I believe this is the intended behavior. When you
select that srs handling option all it does it tell GeoServer to
reproject whenever outputting.. so I would exect the state plane bounds
to be what shows up in say a capabilities document... but see no reason
why info.xml should not store the native bounds.
Andrea can give you a more decisive answer.
-Justin
Bob Nutsch wrote:
> Hi,
>
> For both shapefiles and SDE vector data I am having a problem with on the
> fly projection when using 1.6 Beta 4, running in Tomcat 5.5, XP, Java
> 1.5.0_13.
>
> The native format of the data is geographic, NAD83. I'm trying to project
> to EPSG 2266 (state plane). In the FeatureType Editor, I enter the 2266 in
> the SRS field, and from the SRS Handling pull-down menu I select 'Reproject
> from native to declared SRS'. I then click on the Generate button and I
> then see the min-max X-Y's correctly calculated from the data extent. I
> scroll down and click on the Submit button then Apply and Save. However, in
> the info.xml for that layer, the min-max values remain unchanged, they still
> reflect lat-long and not state plane.
>
> Am I missing something or is this a feature?
>
> Thanks, Bob
>
>
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Hi,
For both shapefiles and SDE vector data I am having a problem with on the
fly projection when using 1.6 Beta 4, running in Tomcat 5.5, XP, Java
1.5.0_13.
The native format of the data is geographic, NAD83. I'm trying to project
to EPSG 2266 (state plane). In the FeatureType Editor, I enter the 2266 in
the SRS field, and from the SRS Handling pull-down menu I select 'Reproject
from native to declared SRS'. I then click on the Generate button and I
then see the min-max X-Y's correctly calculated from the data extent. I
scroll down and click on the Submit button then Apply and Save. However, in
the info.xml for that layer, the min-max values remain unchanged, they still
reflect lat-long and not state plane.
Am I missing something or is this a feature?
Thanks, Bob
--
View this message in context: http://www.nabble.com/Problem-with-on-the-fly-projection-tf4720367.html#a13494668
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Chris Holmes a écrit :
> It seems to meet Justin's criteria of using a standard library, it'll
> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot better
> than commons logging.
SLF4J has more capabilities than Commons-Logging for sure. But the most standard
(while maybe not the most used) API stay Java Logging, since it is bundled in
core Java. It is also the less troublesome (because of its priviligied position
in core Java, compared to other framework) for those who are willing to accept
its limitations, especially if we want to use GeoServer inside Glassfish.
Commons-Logging seems to be slowly dying because of ClassLoader issues
(Hibernate is moving from Commons-Logging to SLF4J because of that, and a
similar move in Jetty (from version 5 to version 6) trigged this logging thread).
I admit that Java Logging has less capabilities than Log4J, which is why it is
important to allow peoples to use other implementations. In order to lets people
choose whatever implementation they want, we need to agree on an API. I suggest
Java Logging API (note: API, not necessarly implementation) because it is core Java.
Writting our own java.util.logging.Logger facade should not be long. I expect
that by the time we get the PMC okay, it will be done the day after. Doing that
in GeoTools allows us to redirect to Log4J or SLF4J, as we wish even if the
container tries to redirect us elsewhere.
As a bonus (not sure if it is useful), we get for free the ability to redirect
different loggers to different Logging framework :) (e.g. "org.geotools.render"
to Log4J, "org.geotools.filter" to Java logging...)
Martin

Andrea Aime a écrit :
> Hmmm... I'm not sure I understand the need of SPI here... I mean, how
> do you decide which one of the implementations to use? If you have
> to provide a hint of some kind, then you may well pass the actual
> factory and be done with it no?
Yes, you are right. Please forget about my SPI proposal.
Martin

Andrea Aime wrote:
> Chris Holmes ha scritto:
>>
>> Andrea Aime wrote:
>>> Chris Holmes ha scritto:
>>>> Ok, I'm trying to get a handle on this issue.
>>>>
>>>> One question, what's the objection to just using SFL4J ?
>>>>
>>>> It seems to meet Justin's criteria of using a standard library, it'll
>>>> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot
>>>> better than commons logging.
>>>>
>>>> I imagine I just missed what the objection was, but I'm curious to
>>>> hear it.
>>> sfl4j is just a facade like commons logging. Now, in Jetty by default
>>> they put an implementation of the library that redirects to "simple
>>> logging". Given that it's the first element in the classpath it'll
>>> override whatever implementation we put in our library, meaning that
>>> we would not be able to force log4j usage unless we manually change
>>> the jars in the Jetty container (remember, slf4j way of doing
>>> redirections is to implement exactly the same classes in the different
>>> jars and have classloading decide which one gets used).
>> But GeoServer isn't relying on any log4g usage, right? Why would we
>> want to force it?
>
> You must have lost some episodes of the logging saga :)
> GeoServer is using log4j since Saul switched GeoServer to use it,
> and 1.6 configures the logging levels using log4j configuration files.
> So yes, either 1.6 uses log4j or it has no control on the logging levels
> whatsoever.
Ah, right. Yeah, I missed that episode. Ok, just ignore me, I have
nothing productive to add :(
In the unproductive vein, however: 'this stuff sucks!' And thank you
all for doing your best to figure out a solution that works.
Chris
> It's just that at the moment we're using the java logging api, which
> redirects to commons logging, which redirects to log4j, and the
> logging level setup is simply not working.
>
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> !DSPAM:4005,4727795931781431913854!
>

Chris Holmes ha scritto:
>
>
> Andrea Aime wrote:
>> Chris Holmes ha scritto:
>>> Ok, I'm trying to get a handle on this issue.
>>>
>>> One question, what's the objection to just using SFL4J ?
>>>
>>> It seems to meet Justin's criteria of using a standard library, it'll
>>> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot
>>> better than commons logging.
>>>
>>> I imagine I just missed what the objection was, but I'm curious to
>>> hear it.
>>
>> sfl4j is just a facade like commons logging. Now, in Jetty by default
>> they put an implementation of the library that redirects to "simple
>> logging". Given that it's the first element in the classpath it'll
>> override whatever implementation we put in our library, meaning that
>> we would not be able to force log4j usage unless we manually change
>> the jars in the Jetty container (remember, slf4j way of doing
>> redirections is to implement exactly the same classes in the different
>> jars and have classloading decide which one gets used).
> But GeoServer isn't relying on any log4g usage, right? Why would we
> want to force it?
You must have lost some episodes of the logging saga :)
GeoServer is using log4j since Saul switched GeoServer to use it,
and 1.6 configures the logging levels using log4j configuration files.
So yes, either 1.6 uses log4j or it has no control on the logging levels
whatsoever.
It's just that at the moment we're using the java logging api, which
redirects to commons logging, which redirects to log4j, and the
logging level setup is simply not working.
Cheers
Andrea

Andrea Aime wrote:
> Chris Holmes ha scritto:
>> Ok, I'm trying to get a handle on this issue.
>>
>> One question, what's the objection to just using SFL4J ?
>>
>> It seems to meet Justin's criteria of using a standard library, it'll
>> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot
>> better than commons logging.
>>
>> I imagine I just missed what the objection was, but I'm curious to
>> hear it.
>
> sfl4j is just a facade like commons logging. Now, in Jetty by default
> they put an implementation of the library that redirects to "simple
> logging". Given that it's the first element in the classpath it'll
> override whatever implementation we put in our library, meaning that
> we would not be able to force log4j usage unless we manually change
> the jars in the Jetty container (remember, slf4j way of doing
> redirections is to implement exactly the same classes in the different
> jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right? Why would we
want to force it?
>
> I guess the second problem is timing, the slf4j is different enough
> from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
> manual changes will have to be performed manually instead of using
> a single search and replace, especially in the modules managed
> by Martin.
>
Hmmm... Let's see what he says.
What about GeoServer using sfl4j and geotools continue to use java
logging? Would that help solve things?
Chris
> Cheers
> Andrea
>
> !DSPAM:4005,472776d522262143011171!
>

Chris Holmes ha scritto:
> Ok, I'm trying to get a handle on this issue.
>
> One question, what's the objection to just using SFL4J ?
>
> It seems to meet Justin's criteria of using a standard library, it'll
> work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot better
> than commons logging.
>
> I imagine I just missed what the objection was, but I'm curious to hear it.
Oh, for an idea of how hard the switch might be have a look at
the differences between java logggin and commons logging:
http://www.slf4j.org/api/org/slf4j/Logger.html
(you'll notice that some cases aren't covered 1:1 by slf4j
either, thought probably it's possible to handle them by using
that Marker thing they have there).
Cheers
Andrea