[Geoserver-devel] New default Config data

So I have been given some new default configuration data to stick into
GeoServer and I have done so.. a set of six shape files added to the
UserBasic configuration.

Uh. Ok, I guess that's fine. Perhaps an explanation on why we feel
these are needed in the default configuration? I'm sort of inclined to
keep it small, so users have a good idea what's going on without having
to wade through a bunch of junk. And so they don't have to remove a
bunch of files to put just their own data in. Though I don't feel
incredibly strongly, but putting more data in the UserBasic
configuration does mean are war is bigger, and I sorta like that being
small, I just did some clean up to get its size down more.

Actually, I meant to bring something up on the size issue. How
necessary is our dependance on xercesImpl? As far as I could tell our
XML configuration writer uses some Output classes. Is there another
way to do this, or do we need xerces? I guess that could be another
argument for the avalon stuff (though it may rely on xerces as well).
I think everything else that xerces does can be done by whatever the
servlet container is using for xml stuff.

I have left the shapefiles as I have given
them, all in one directory, with the feature type's xml files in their
own directory as GeoServer has generated them.

Hrm, I'm not sure about this, as we recommend to users they put them in
their own folder. Though for shapefiles it really would be nice if a
datastore could be a directory. I would not be nearly so anal about
this stuff if it wasn't in UserBasic, because UserBasic is what goes
out to all of our users, so it really should look good and make perfect
sense. And having a geoserverdemo folder in their main conf/ folder
makes it seem like its a standard folder, when it's really not.

You could make a confGeoServerDemo, like confCitePostGis and
confUserBasic, and I won't be so anal. Though I feel that too is
slightly weird, having the demo in the source code. But if that's what
you'd like, go for it, I don't feel too strongly.

Also note that the catalog.xml and services.xml that it uses now (that
GeoServer generated for me) are quite ugly.

Yeah, that's unacceptable. Sorry. You're going to have to not use the
generated GeoServer ones. Just bring up the old ones and cut and paste
the new lines in from the generated ones. It's really important that
those files look nice, as they are the entry point for users who are
not interested in the web interface, and they will stay unmangled as
long as you don't use the web interface.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

I can look into the preaty printer a bit ... tried to keep it close, so probably
there are some bugs here.

David

Quoting cholmes@anonymised.com:

> So I have been given some new default configuration data to stick into
> GeoServer and I have done so.. a set of six shape files added to the
> UserBasic configuration.
Uh. Ok, I guess that's fine. Perhaps an explanation on why we feel
these are needed in the default configuration? I'm sort of inclined to
keep it small, so users have a good idea what's going on without having
to wade through a bunch of junk. And so they don't have to remove a
bunch of files to put just their own data in. Though I don't feel
incredibly strongly, but putting more data in the UserBasic
configuration does mean are war is bigger, and I sorta like that being
small, I just did some clean up to get its size down more.

Actually, I meant to bring something up on the size issue. How
necessary is our dependance on xercesImpl? As far as I could tell our
XML configuration writer uses some Output classes. Is there another
way to do this, or do we need xerces? I guess that could be another
argument for the avalon stuff (though it may rely on xerces as well).
I think everything else that xerces does can be done by whatever the
servlet container is using for xml stuff.

> I have left the shapefiles as I have given
> them, all in one directory, with the feature type's xml files in their
> own directory as GeoServer has generated them.
Hrm, I'm not sure about this, as we recommend to users they put them in
their own folder. Though for shapefiles it really would be nice if a
datastore could be a directory. I would not be nearly so anal about
this stuff if it wasn't in UserBasic, because UserBasic is what goes
out to all of our users, so it really should look good and make perfect
sense. And having a geoserverdemo folder in their main conf/ folder
makes it seem like its a standard folder, when it's really not.

You could make a confGeoServerDemo, like confCitePostGis and
confUserBasic, and I won't be so anal. Though I feel that too is
slightly weird, having the demo in the source code. But if that's what
you'd like, go for it, I don't feel too strongly.

>
> Also note that the catalog.xml and services.xml that it uses now (that
> GeoServer generated for me) are quite ugly.

Yeah, that's unacceptable. Sorry. You're going to have to not use the
generated GeoServer ones. Just bring up the old ones and cut and paste
the new lines in from the generated ones. It's really important that
those files look nice, as they are the entry point for users who are
not interested in the web interface, and they will stay unmangled as
long as you don't use the web interface.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Is there a confCitePostGis somewhere? I would like to try it.

I was trying to set up a datasource from postgresql. I converted a
shape file into postgis. When I query from the browser, it
displays empty, and I only saw an error from Tomcat:
15713 [SEVERE] org.geotools.renderer.lite.LiteRenderer - I/O error while
rendering the layer

I googled the error and nothing was found.

I found I do not know where to start to figure out the problem.

Any help is appreciated.

Changqing

On Fri, 9 Apr 2004 cholmes@anonymised.com wrote:

> So I have been given some new default configuration data to stick into
> GeoServer and I have done so.. a set of six shape files added to the
> UserBasic configuration.
Uh. Ok, I guess that's fine. Perhaps an explanation on why we feel
these are needed in the default configuration? I'm sort of inclined to
keep it small, so users have a good idea what's going on without having
to wade through a bunch of junk. And so they don't have to remove a
bunch of files to put just their own data in. Though I don't feel
incredibly strongly, but putting more data in the UserBasic
configuration does mean are war is bigger, and I sorta like that being
small, I just did some clean up to get its size down more.

Actually, I meant to bring something up on the size issue. How
necessary is our dependance on xercesImpl? As far as I could tell our
XML configuration writer uses some Output classes. Is there another
way to do this, or do we need xerces? I guess that could be another
argument for the avalon stuff (though it may rely on xerces as well).
I think everything else that xerces does can be done by whatever the
servlet container is using for xml stuff.

> I have left the shapefiles as I have given
> them, all in one directory, with the feature type's xml files in their
> own directory as GeoServer has generated them.
Hrm, I'm not sure about this, as we recommend to users they put them in
their own folder. Though for shapefiles it really would be nice if a
datastore could be a directory. I would not be nearly so anal about
this stuff if it wasn't in UserBasic, because UserBasic is what goes
out to all of our users, so it really should look good and make perfect
sense. And having a geoserverdemo folder in their main conf/ folder
makes it seem like its a standard folder, when it's really not.

You could make a confGeoServerDemo, like confCitePostGis and
confUserBasic, and I won't be so anal. Though I feel that too is
slightly weird, having the demo in the source code. But if that's what
you'd like, go for it, I don't feel too strongly.

>
> Also note that the catalog.xml and services.xml that it uses now (that
> GeoServer generated for me) are quite ugly.

Yeah, that's unacceptable. Sorry. You're going to have to not use the
generated GeoServer ones. Just bring up the old ones and cut and paste
the new lines in from the generated ones. It's really important that
those files look nice, as they are the entry point for users who are
not interested in the web interface, and they will stay unmangled as
long as you don't use the web interface.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I figured out the problem: wrong bounding box specified in the url.

However, what helped was an email from Chris which mentioned log level
finer...didnt know I can do that! So I tuned mine to FINEST... there you
go... the postgresql sql is there!

I wish the default log level to be set to FINEST...so much easier for
beginners.

Changqing

On Sun, 11 Apr 2004, Changqing Zhou wrote:

Is there a confCitePostGis somewhere? I would like to try it.

I was trying to set up a datasource from postgresql. I converted a
shape file into postgis. When I query from the browser, it
displays empty, and I only saw an error from Tomcat:
15713 [SEVERE] org.geotools.renderer.lite.LiteRenderer - I/O error while
rendering the layer

I googled the error and nothing was found.

I found I do not know where to start to figure out the problem.

Any help is appreciated.

Changqing

On Fri, 9 Apr 2004 cholmes@anonymised.com wrote:

> > So I have been given some new default configuration data to stick into
> > GeoServer and I have done so.. a set of six shape files added to the
> > UserBasic configuration.
> Uh. Ok, I guess that's fine. Perhaps an explanation on why we feel
> these are needed in the default configuration? I'm sort of inclined to
> keep it small, so users have a good idea what's going on without having
> to wade through a bunch of junk. And so they don't have to remove a
> bunch of files to put just their own data in. Though I don't feel
> incredibly strongly, but putting more data in the UserBasic
> configuration does mean are war is bigger, and I sorta like that being
> small, I just did some clean up to get its size down more.
>
> Actually, I meant to bring something up on the size issue. How
> necessary is our dependance on xercesImpl? As far as I could tell our
> XML configuration writer uses some Output classes. Is there another
> way to do this, or do we need xerces? I guess that could be another
> argument for the avalon stuff (though it may rely on xerces as well).
> I think everything else that xerces does can be done by whatever the
> servlet container is using for xml stuff.
>
> > I have left the shapefiles as I have given
> > them, all in one directory, with the feature type's xml files in their
> > own directory as GeoServer has generated them.
> Hrm, I'm not sure about this, as we recommend to users they put them in
> their own folder. Though for shapefiles it really would be nice if a
> datastore could be a directory. I would not be nearly so anal about
> this stuff if it wasn't in UserBasic, because UserBasic is what goes
> out to all of our users, so it really should look good and make perfect
> sense. And having a geoserverdemo folder in their main conf/ folder
> makes it seem like its a standard folder, when it's really not.
>
> You could make a confGeoServerDemo, like confCitePostGis and
> confUserBasic, and I won't be so anal. Though I feel that too is
> slightly weird, having the demo in the source code. But if that's what
> you'd like, go for it, I don't feel too strongly.
>
> >
> > Also note that the catalog.xml and services.xml that it uses now (that
> > GeoServer generated for me) are quite ugly.
>
> Yeah, that's unacceptable. Sorry. You're going to have to not use the
> generated GeoServer ones. Just bring up the old ones and cut and paste
> the new lines in from the generated ones. It's really important that
> those files look nice, as they are the entry point for users who are
> not interested in the web interface, and they will stay unmangled as
> long as you don't use the web interface.
>
>
> Chris
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel