[Geoserver-devel] A data directory for the new millennium

GeoServer GeoServer Developer
1

Hi there. Ivan and I have been looking to improve the data directory we ship with GeoServer, and have come up with the following suggestions for improvement.

1. Spearfish. The spearfish data we include are five vector layers one raster layer, compiled together into a layer group. We are looking to see if we can find better data layers from the Spearfish dataset, and/or restyling the existing layers.

2. Tiger namespace layers are pretty awful. We would like to remove this and replace with a slimmed-down version of the NYC demo (as seen on our homepage). (See #11)

3. topp:states. Ahh, how can we do anything with this one? :slight_smile: The layer has a good amount of metadata, so I think a restyle is all that's needed.

4. The rest of the topp namespace layers are part of the WFS-T (Tasmania) demo. We would like to update this WFS-T demo, preferably with a different/nicer dataset, and then retire this one. This is a slightly separate issue (involving design considerations and JavaScript) so this section may be pushed back (a future email to follow).

5. The nurc:Arc_Sample (Precipitation raster layer) layer can remain. It's not excellent, but it's a good example of a raster layer that's _not_ an elevation model.

6. nurc:Img_Sample (Blue Marble). We would like to upgrade this to a slightly higher quality (not too large, but better than what we have).

7. nurc:Pk50095 (the topo map chunk). We're not quite sure what to do with this, but would like to replace this with something more useful/complete. Perhaps another freely distributable (and small) topo map.

8. nurc:mosaic (Image mosaic). The quality isn't great, but it's a good example of an image mosaic, so we have no problem leaving this as is for the time being.

9. We would like to add a layer showing worldwide country boundaries. If nothing else, perhaps this could replace topp:states as the layer of choice (and would be a good way to internationalize our dataset).

10. For all layers, we would uses aliases to make the layers more obvious as to what they are (ex: nurc:Img_Sample -> Blue Marble Imagery)

11. We would like to retire/destroy the current "WMS Example" of Manhattan. (See #2) We can do much better. :slight_smile: This might also involve design/JavaScript needs, so this may be pushed back as well.

Sorry for the long list. The goal is to create a data directory that showcases the wide range of functionality that GeoServer provides out of the box.

If anyone has any suggestions, please let me know. If no one has any objections, I will turn this list into a JIRA task (or perhaps a collection of JIRA tasks).

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

2

Mike Pumphrey ha scritto:

Hi there. Ivan and I have been looking to improve the data directory we ship with GeoServer, and have come up with the following suggestions for improvement.

1. Spearfish. The spearfish data we include are five vector layers one raster layer, compiled together into a layer group. We are looking to see if we can find better data layers from the Spearfish dataset, and/or restyling the existing layers.

2. Tiger namespace layers are pretty awful. We would like to remove this and replace with a slimmed-down version of the NYC demo (as seen on our homepage). (See #11)

3. topp:states. Ahh, how can we do anything with this one? :slight_smile: The layer has a good amount of metadata, so I think a restyle is all that's needed.

4. The rest of the topp namespace layers are part of the WFS-T (Tasmania) demo. We would like to update this WFS-T demo, preferably with a different/nicer dataset, and then retire this one. This is a slightly separate issue (involving design considerations and JavaScript) so this section may be pushed back (a future email to follow).

5. The nurc:Arc_Sample (Precipitation raster layer) layer can remain. It's not excellent, but it's a good example of a raster layer that's _not_ an elevation model.

6. nurc:Img_Sample (Blue Marble). We would like to upgrade this to a slightly higher quality (not too large, but better than what we have).

7. nurc:Pk50095 (the topo map chunk). We're not quite sure what to do with this, but would like to replace this with something more useful/complete. Perhaps another freely distributable (and small) topo map.

8. nurc:mosaic (Image mosaic). The quality isn't great, but it's a good example of an image mosaic, so we have no problem leaving this as is for the time being.

9. We would like to add a layer showing worldwide country boundaries. If nothing else, perhaps this could replace topp:states as the layer of choice (and would be a good way to internationalize our dataset).

10. For all layers, we would uses aliases to make the layers more obvious as to what they are (ex: nurc:Img_Sample -> Blue Marble Imagery)

11. We would like to retire/destroy the current "WMS Example" of Manhattan. (See #2) We can do much better. :slight_smile: This might also involve design/JavaScript needs, so this may be pushed back as well.

Sorry for the long list. The goal is to create a data directory that showcases the wide range of functionality that GeoServer provides out of the box.

If anyone has any suggestions, please let me know. If no one has any objections, I will turn this list into a JIRA task (or perhaps a collection of JIRA tasks).

I'm good with having nicer demos. However, wondering what the
extra weight to carry out is going to be. Not everybody has a fast
internet connection.
Where I live the fastest you can get is 4mbit/s, which is still
acceptable to download up to 50-100 or so MB without getting old waiting
for the download, but in many countries the current weight is
already a problem either for the speed, of because you have to
pay for each MB downloaded.

Also consider the data we ship was not that bad in origin, it
was heavily generalized in order to reduce its size (both states
and the tiger data afaik).
And oh, there is also the rendering speed issue I guess... the
more data you want to display, the longer it takes to draw it.
The current tiger demo is already not exactly a rocket...

Personally I would like to see a slim down cure in the libraries (jars)
before we take in more data (see my xml libs cleanup topic, that did not
get much follow up...).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

Hi Andrea. Thanks for your thoughts. Currently, the data directory that ship with GeoServer is roughly 3MB out of about 43MB when compressed (or 10% of the download). I don't think we wish to increase the size of the data directory too much, but even if we doubled it (which we won't), at current compression rates, that would make the download size 46MB instead of 43MB. Regardless, I think we can be slick and slim at the same time. :slight_smile:

As for rendering speed, yes, that could be an issue, and we'll keep an eye on it as we comb through the data directory.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Andrea Aime wrote:

Mike Pumphrey ha scritto:

Hi there. Ivan and I have been looking to improve the data directory we ship with GeoServer, and have come up with the following suggestions for improvement.

1. Spearfish. The spearfish data we include are five vector layers one raster layer, compiled together into a layer group. We are looking to see if we can find better data layers from the Spearfish dataset, and/or restyling the existing layers.

2. Tiger namespace layers are pretty awful. We would like to remove this and replace with a slimmed-down version of the NYC demo (as seen on our homepage). (See #11)

3. topp:states. Ahh, how can we do anything with this one? :slight_smile: The layer has a good amount of metadata, so I think a restyle is all that's needed.

4. The rest of the topp namespace layers are part of the WFS-T (Tasmania) demo. We would like to update this WFS-T demo, preferably with a different/nicer dataset, and then retire this one. This is a slightly separate issue (involving design considerations and JavaScript) so this section may be pushed back (a future email to follow).

5. The nurc:Arc_Sample (Precipitation raster layer) layer can remain. It's not excellent, but it's a good example of a raster layer that's _not_ an elevation model.

6. nurc:Img_Sample (Blue Marble). We would like to upgrade this to a slightly higher quality (not too large, but better than what we have).

7. nurc:Pk50095 (the topo map chunk). We're not quite sure what to do with this, but would like to replace this with something more useful/complete. Perhaps another freely distributable (and small) topo map.

8. nurc:mosaic (Image mosaic). The quality isn't great, but it's a good example of an image mosaic, so we have no problem leaving this as is for the time being.

9. We would like to add a layer showing worldwide country boundaries. If nothing else, perhaps this could replace topp:states as the layer of choice (and would be a good way to internationalize our dataset).

10. For all layers, we would uses aliases to make the layers more obvious as to what they are (ex: nurc:Img_Sample -> Blue Marble Imagery)

11. We would like to retire/destroy the current "WMS Example" of Manhattan. (See #2) We can do much better. :slight_smile: This might also involve design/JavaScript needs, so this may be pushed back as well.

Sorry for the long list. The goal is to create a data directory that showcases the wide range of functionality that GeoServer provides out of the box.

If anyone has any suggestions, please let me know. If no one has any objections, I will turn this list into a JIRA task (or perhaps a collection of JIRA tasks).

I'm good with having nicer demos. However, wondering what the
extra weight to carry out is going to be. Not everybody has a fast
internet connection.
Where I live the fastest you can get is 4mbit/s, which is still
acceptable to download up to 50-100 or so MB without getting old waiting
for the download, but in many countries the current weight is
already a problem either for the speed, of because you have to
pay for each MB downloaded.

Also consider the data we ship was not that bad in origin, it
was heavily generalized in order to reduce its size (both states
and the tiger data afaik).
And oh, there is also the rendering speed issue I guess... the
more data you want to display, the longer it takes to draw it.
The current tiger demo is already not exactly a rocket...

Personally I would like to see a slim down cure in the libraries (jars)
before we take in more data (see my xml libs cleanup topic, that did not
get much follow up...).

Cheers
Andrea