[Geoserver-users] Bounds of datastore based on "empty" Shapefile

Damiano_Albani · January 21, 2014, 4:08pm

Hello,

When uploading an “empty” Shapefile (i.e. with no features), it looks like GeoServer configures the datastore with bounds being equal to what is explicitly specified in the Shapefile.
And clicking on “compute from data” in the configuration page doesn’t make the value change.
So what bounds should be advertised for layers of this kind? All zeros? That’s what OGR does apparently:

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (19496742305194890055511892394450289164288.000000, 19496742305194890055511892394450289164288.000000) - (-19496742305194890055511892394450289164288.000000, -19496742305194890055511892394450289164288.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

$ ogrinfo -sql ‘RECOMPUTE EXTENT ON empty’ empty.shp

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

I know it doesn’t make much sense to work with empty Shapefiles but I have to handle this case, having a user-exposed GeoServer.
More precisely, I have an application which queries GeoServer for layers information and then feeds it to OpenLayers for WMS rendering.
And I can confirm that OpenLayers really chokes on extent values like the weird one shown above

Thanks for your help!

–
Damiano Albani

Andrea_Aime4 · January 21, 2014, 4:29pm

On Tue, Jan 21, 2014 at 5:08 PM, Damiano Albani <damiano.albani@anonymised.com>wrote:

Hello,

When uploading an "empty" Shapefile (i.e. with no features), it looks like
GeoServer configures the datastore with bounds being equal to what is
explicitly specified in the Shapefile.
And clicking on "compute from data" in the configuration page doesn't make
the value change.
So what bounds should be advertised for layers of this kind? All zeros?
That's what OGR does apparently:

$ ogrinfo -al empty.shp
  Layer name: empty
  Geometry: Line String
  Feature Count: 0
  Extent: (19496742305194890055511892394450289164288.000000,
19496742305194890055511892394450289164288.000000) -
(-19496742305194890055511892394450289164288.000000,
-19496742305194890055511892394450289164288.000000)
  Layer SRS WKT:
  GEOGCS["GCS_WGS_84",
      DATUM["WGS_84",
          SPHEROID["WGS84",6378137,000,298,257223563]],
      PRIMEM["Greenwich",0.0],
      UNIT["Degree",0.0174532925199433]]
  ID: String (10.0)
  ...

$ ogrinfo -sql 'RECOMPUTE EXTENT ON empty' empty.shp

$ ogrinfo -al empty.shp
  Layer name: empty
  Geometry: Line String
  Feature Count: 0
  Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
  Layer SRS WKT:
  GEOGCS["GCS_WGS_84",
      DATUM["WGS_84",
          SPHEROID["WGS84",6378137,000,298,257223563]],
      PRIMEM["Greenwich",0.0],
      UNIT["Degree",0.0174532925199433]]
  ID: String (10.0)
  ...

I know it doesn't make much sense to work with empty Shapefiles but I have
to handle this case, having a user-exposed GeoServer.
More precisely, I have an application which queries GeoServer for layers
information and then feeds it to OpenLayers for WMS rendering.
And I can confirm that OpenLayers really chokes on extent values like the
weird one shown above

GeoServer does not have a way to dodge the values contained in the headers
and do a manual scan.
It would be possible to implement it though, but it would have to be
optional, scanning thorough large
data sources can take ages (as in hours, and during that time, the admin
interface is locked)

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Jonathan_Moules2 · January 21, 2014, 5:47pm

It would be possible to implement it though, but it would have to be optional, scanning thorough large

data sources can take ages

A good potential intermediate solution would be to scan the first n features all the time. Where n is something configurable. Want it disabled? Set to 0. What everything? Set to 999999999. But with a “sensible” default of 1000 or something (random number).

As a bonus that would obviate Damiano’s issue.
Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

carlo_cancellieri · January 21, 2014, 6:54pm

Andrea,
what about performing a count then add something like this?
If count ==0 then
Bbox = 0 0 0 0
Carlo

Il 21/gen/2014 17:37 “Andrea Aime” <andrea.aime@anonymised.com> ha scritto:

On Tue, Jan 21, 2014 at 5:08 PM, Damiano Albani <damiano.albani@anonymised.com> wrote:

Hello,

When uploading an “empty” Shapefile (i.e. with no features), it looks like GeoServer configures the datastore with bounds being equal to what is explicitly specified in the Shapefile.
And clicking on “compute from data” in the configuration page doesn’t make the value change.
So what bounds should be advertised for layers of this kind? All zeros? That’s what OGR does apparently:

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (19496742305194890055511892394450289164288.000000, 19496742305194890055511892394450289164288.000000) - (-19496742305194890055511892394450289164288.000000, -19496742305194890055511892394450289164288.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

$ ogrinfo -sql ‘RECOMPUTE EXTENT ON empty’ empty.shp

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

I know it doesn’t make much sense to work with empty Shapefiles but I have to handle this case, having a user-exposed GeoServer.
More precisely, I have an application which queries GeoServer for layers information and then feeds it to OpenLayers for WMS rendering.
And I can confirm that OpenLayers really chokes on extent values like the weird one shown above

GeoServer does not have a way to dodge the values contained in the headers and do a manual scan.
It would be possible to implement it though, but it would have to be optional, scanning thorough large
data sources can take ages (as in hours, and during that time, the admin interface is locked)

Cheers
Andrea

–
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Andrea_Aime4 · January 21, 2014, 9:33pm

On Tue, Jan 21, 2014 at 7:54 PM, carlo cancellieri <
carlo.cancellieri@anonymised.com> wrote:

Andrea,
what about performing a count then add something like this?
If count ==0 then
Bbox = 0 0 0 0

Try doing select count(*) on a oracle table with 50 millions polygon and
see how many
minutes you have to wait to get the result.
Doing a count with a "limit 1" should be fast enough though, that could work

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Damiano_Albani · January 22, 2014, 9:29am

Hello,

On Tue, Jan 21, 2014 at 7:54 PM, carlo cancellieri <
carlo.cancellieri@anonymised.com> wrote:

what about performing a count then add something like this?
If count ==0 then
Bbox = 0 0 0 0

Yes, that's what I had in mind to begin with: handle the "empty" situation
as a special case, where the bbox is necessarily empty as well.

Then, as Jonathan suggested, a more complex implementation could be
devised, which would recompute the extent explicitly, depending on a user
configurable setting if necessary.

But this mechanism depends on GeoServer (thus GeoTools?) being able to
count the number of features in a Shapefile at very little CPU cost. Is
that the case?

On Tue, Jan 21, 2014 at 10:33 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

Try doing select count(*) on a oracle table with 50 millions polygon and
see how many
minutes you have to wait to get the result.
Doing a count with a "limit 1" should be fast enough though, that could
work

And, by the way, what about PostgreSQL / PostGIS?
Triggering "compute from data" in GeoServer runs this kind of query:

select ST_AsText(ST_force_2d(ST_Envelope(ST_Estimated_Extent('public',
'table', 'geom'))))

Based on cached statistics, it runs fast -- and the user can decide to
recompute the extent with VACUUM, as per the documentation.

But, anyway, my initial request was specifically focused on empty
*Shapefiles*.

Regards,

--
Damiano Albani

Andrea_Aime4 · January 22, 2014, 9:43am

On Wed, Jan 22, 2014 at 10:29 AM, Damiano Albani
<damiano.albani@anonymised.com>wrote:

But, anyway, my initial request was specifically focused on empty
*Shapefiles*.

GeoServer code never knows what data store it is working against, so trying
to reason only
about shapefiles is completely pointless

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Damiano_Albani · January 22, 2014, 9:48am

On Wed, Jan 22, 2014 at 10:43 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

GeoServer code never knows what data store it is working against, so
trying to reason only
about shapefiles is completely pointless

Well, I thought I had seen the term "Shapefile" mentioned a couple of times
in GeoServer admin interface...

--
Damiano Albani

ianturton · January 22, 2014, 10:25am

Infact the first envelope is more useful than the second - as you can check if width (or height) is negative with the first and thus infer that it is empty while with the second it is either empty or a point in the centre of Null Island (see https://en.wikipedia.org/wiki/Null_Island) and thus might be empty or not depending on the number of records in the shapefile (which as Andrea pointts out could be expensive to calculate).

I’m pretty sure GeoTools stores empty envelopes as an inside out infinite envelope when they are empty (it certainly used to) so that you can easily add points to the empty envelope to expand it with out having to handle any special cases for empty or half empty envelopes.

Ian

···

On 21 January 2014 16:08, Damiano Albani <damiano.albani@anonymised.com> wrote:

Hello,

When uploading an “empty” Shapefile (i.e. with no features), it looks like GeoServer configures the datastore with bounds being equal to what is explicitly specified in the Shapefile.
And clicking on “compute from data” in the configuration page doesn’t make the value change.
So what bounds should be advertised for layers of this kind? All zeros? That’s what OGR does apparently:

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (19496742305194890055511892394450289164288.000000, 19496742305194890055511892394450289164288.000000) - (-19496742305194890055511892394450289164288.000000, -19496742305194890055511892394450289164288.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

$ ogrinfo -sql ‘RECOMPUTE EXTENT ON empty’ empty.shp

$ ogrinfo -al empty.shp
Layer name: empty
Geometry: Line String
Feature Count: 0
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
GEOGCS[“GCS_WGS_84”,
DATUM[“WGS_84”,
SPHEROID[“WGS84”,6378137,000,298,257223563]],
PRIMEM[“Greenwich”,0.0],
UNIT[“Degree”,0.0174532925199433]]
ID: String (10.0)
…

I know it doesn’t make much sense to work with empty Shapefiles but I have to handle this case, having a user-exposed GeoServer.
More precisely, I have an application which queries GeoServer for layers information and then feeds it to OpenLayers for WMS rendering.
And I can confirm that OpenLayers really chokes on extent values like the weird one shown above

Thanks for your help!

–
Damiano Albani

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Ian Turton

Andrea_Aime4 · January 22, 2014, 10:38am

On Wed, Jan 22, 2014 at 10:48 AM, Damiano Albani
<damiano.albani@anonymised.com>wrote:

On Wed, Jan 22, 2014 at 10:43 AM, Andrea Aime <
andrea.aime@anonymised.com> wrote:

GeoServer code never knows what data store it is working against, so
trying to reason only
about shapefiles is completely pointless

Well, I thought I had seen the term "Shapefile" mentioned a couple of
times in GeoServer admin interface...

Yes, in GeoServer there is one class that knows what a shapefile is, it's
the configuration panel
where you put the location of the shapefile (and the new importer extension
too).
Everything else is done via interfaces, and due to security
related wrappers, it's normally hard to know what a store is anyways (it's
still possible, but hard and not advisable)

For your specific case I believe the issue should be solved at the level of
your application:
* configure the shapefile using REST config (this is already what you're
doing I assume?)
* make a GetFeature and see if the result is empty
* if so, use against REST config to fix the layer bounding box, but don't
set it to all zeros,
as some OGC clients may fail if you do so (they don't have anymore a
knowledge about where the
layer is in the world, cannot setup a valid request against it), make it
represent your area of interest instead

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Damiano_Albani · January 22, 2014, 10:40am

On Wed, Jan 22, 2014 at 11:25 AM, Ian Turton <ijturton@anonymised.com> wrote:

Infact the first envelope is more useful than the second - as you can
check if width (or height) is negative with the first and thus infer that
it is empty while with the second it is either empty or a point in the
centre of Null Island (see https://en.wikipedia.org/wiki/Null_Island) and
thus might be empty or not depending on the number of records in the
shapefile (which as Andrea pointts out could be expensive to calculate).

By "first envelope", do you mean the one with large numbers?
Because these numbers are totally arbitrary, in the sense that the user is
free to upload any kind of Shapefile he wants.
So I'm afraid we can't rely on these numbers only to infer anything about
the "real" extent.

I'm pretty sure GeoTools stores empty envelopes as an inside out infinite
envelope when they are empty (it certainly used to) so that you can easily
add points to the empty envelope to expand it with out having to handle any
special cases for empty or half empty envelopes.

So what is the representation of this "empty envelope"? Would it make sense
to assign it to an empty datastore?

--
Damiano Albani

Damiano_Albani · January 22, 2014, 11:21am

On Wed, Jan 22, 2014 at 11:38 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

Yes, in GeoServer there is one class that knows what a shapefile is,
it's the configuration panel
where you put the location of the shapefile (and the new importer
extension too).
Everything else is done via interfaces, and due to security
related wrappers, it's normally hard to know what a store is anyways (it's
still possible, but hard and not advisable)

That makes sense, indeed.

For your specific case I believe the issue should be solved at the level

of your application:
* configure the shapefile using REST config (this is already what you're
doing I assume?)

Yes, that's how I upload it.

* make a GetFeature and see if the result is empty

I suppose you mean a request like this:

http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=workspace1:39273642-1d56-4044-8561-979019900eac&maxFeatures=1
"

Then it returns:

<wfs:FeatureCollection [...]>
<gml:boundedBy><gml:null>unknown</gml:null></gml:boundedBy>
</wfs:FeatureCollection>

By the way, is that response valid-ish with regard to "gml:null" and
"unknown" values?

In fact, I've just discovered that querying WFS in version 2.0.0 returns a
more legible result:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=workspace1:39273642-1d56-4044-8561-979019900eac&count=1

<wfs:FeatureCollection [...] numberMatched="0" numberReturned="0"
timeStamp="2014-01-22T11:15:10.868Z"/>

* if so, use against REST config to fix the layer bounding box, but
don't set it to all zeros,
as some OGC clients may fail if you do so (they don't have anymore a
knowledge about where the
layer is in the world, cannot setup a valid request against it), make
it represent your area of interest instead

Well, I don't know what would be the proper "area of interest" in my case.
It has to be "generic".
And what about setting the bounding box to the whole area of the applicable
reference system?

--
Damiano Albani

ianturton · January 22, 2014, 11:29am

I mean this one:
Extent: (19496742305194890055511892394450289164288.000000, 19496742305194890055511892394450289164288.000000) - (-19496742305194890055511892394450289164288.000000, -19496742305194890055511892394450289164288.000000)

If you look the lower left corner (the first one) is above and to the right of the upper right corner (the second). This means that the width of the box is negative.

It’s a pretty standard representation.

Ian

···

On 22 January 2014 10:40, Damiano Albani <damiano.albani@anonymised.com> wrote:

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Ian Turton

On Wed, Jan 22, 2014 at 11:25 AM, Ian Turton <ijturton@anonymised.com> wrote:

Infact the first envelope is more useful than the second - as you can check if width (or height) is negative with the first and thus infer that it is empty while with the second it is either empty or a point in the centre of Null Island (see https://en.wikipedia.org/wiki/Null_Island) and thus might be empty or not depending on the number of records in the shapefile (which as Andrea pointts out could be expensive to calculate).

By “first envelope”, do you mean the one with large numbers?
Because these numbers are totally arbitrary, in the sense that the user is free to upload any kind of Shapefile he wants.
So I’m afraid we can’t rely on these numbers only to infer anything about the “real” extent.

I’m pretty sure GeoTools stores empty envelopes as an inside out infinite envelope when they are empty (it certainly used to) so that you can easily add points to the empty envelope to expand it with out having to handle any special cases for empty or half empty envelopes.

So what is the representation of this “empty envelope”? Would it make sense to assign it to an empty datastore?

–
Damiano Albani

Andrea_Aime4 · January 22, 2014, 11:37am

On Wed, Jan 22, 2014 at 12:21 PM, Damiano Albani
<damiano.albani@anonymised.com>wrote:

On Wed, Jan 22, 2014 at 11:38 AM, Andrea Aime <
andrea.aime@anonymised.com> wrote:

Yes, in GeoServer there is one class that knows what a shapefile is,
it's the configuration panel
where you put the location of the shapefile (and the new importer
extension too).
Everything else is done via interfaces, and due to security
related wrappers, it's normally hard to know what a store is anyways
(it's still possible, but hard and not advisable)

That makes sense, indeed.

For your specific case I believe the issue should be solved at the level

of your application:
* configure the shapefile using REST config (this is already what you're
doing I assume?)

Yes, that's how I upload it.

* make a GetFeature and see if the result is empty

I suppose you mean a request like this:

http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=workspace1:39273642-1d56-4044-8561-979019900eac&maxFeatures=1
"

Then it returns:

<wfs:FeatureCollection [...]>
<gml:boundedBy><gml:null>unknown</gml:null></gml:boundedBy>
</wfs:FeatureCollection>

By the way, is that response valid-ish with regard to "gml:null" and
"unknown" values?

Yes, it's valid. Forget about the boundedBy and check if you get any
feature or not in the output (in the one above, you have no features).

In fact, I've just discovered that querying WFS in version 2.0.0 returns a
more legible result:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=workspace1:39273642-1d56-4044-8561-979019900eac&count=1

<wfs:FeatureCollection [...] numberMatched="0" numberReturned="0"
timeStamp="2014-01-22T11:15:10.868Z"/>

Different protocols, different requirements, in WFS 1.1 we cannot avoid
adding the boundedBy element (it's mandatory) but it's ok to report it as
gml:null.

* if so, use against REST config to fix the layer bounding box, but
don't set it to all zeros,
as some OGC clients may fail if you do so (they don't have anymore a
knowledge about where the
layer is in the world, cannot setup a valid request against it), make
it represent your area of interest instead

Well, I don't know what would be the proper "area of interest" in my case.
It has to be "generic".
And what about setting the bounding box to the whole area of the
applicable reference system?

Yes, that's an idea. Mind, the "whole area application to reference system"
is something that is sometimes not known by GeoServer,
and there is no API that you can use to get it, when GeoServer can extract
it from the EPSG database.
So it would have to be something your application knows instead.

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Damiano_Albani · January 23, 2014, 10:55am

On Wed, Jan 22, 2014 at 12:29 PM, Ian Turton <ijturton@anonymised.com> wrote:

I mean this one:
Extent: (19496742305194890055511892394450289164288.000000,
19496742305194890055511892394450289164288.000000) - (-
19496742305194890055511892394450289164288.000000, -
19496742305194890055511892394450289164288.000000)

If you look the lower left corner (the first one) is above and to the
right of the upper right corner (the second). This means that the width of
the box is negative.

It's a pretty standard representation.

OK, I didn't know about this kind of representation. Thanks for the tip.
But still, as I said previously, I consider these numbers in the Shapefile
definition as no more than a *hint*: only the extent calculated from the
features can "trusted".

--
Damiano Albani

Damiano_Albani · January 23, 2014, 11:45am

On Wed, Jan 22, 2014 at 12:37 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

Yes, that's an idea. Mind, the "whole area application to reference
system" is something that is sometimes not known by GeoServer,
and there is no API that you can use to get it, when GeoServer can extract
it from the EPSG database.
So it would have to be something your application knows instead.

While we're on this topic, have you considered providing a REST interface
to the EPSG database available to GeoServer?
There's this "SRS List" page in the "demos" section that resembles what I'm
talking about.
Then in my case I would use the field "Area of validity" as the bounding
box in the case of empty datasources.

I also would like to come back to what you said initially:

On Tue, Jan 21, 2014 at 5:29 PM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

GeoServer does not have a way to dodge the values contained in the headers
and do a manual scan.
It would be possible to implement it though, but it would have to be
optional, scanning thorough large
data sources can take ages (as in hours, and during that time, the admin
interface is locked)

I've just discovered that there exists a REST API that provides a
"recalculate" option<http://docs.geoserver.org/stable/en/user/rest/api/featuretypes.html#recalculate>for
vector layers.
Unfortunately, even fiddling with the various options listed in the doc, I
haven't been able to trigger the calculation of the bounding box based on
the actual features.
Shouldn't it be the proper way to run this "manual scan" that you mentioned
above?

As we've discussed previously, it's possible indeed to somewhat handle the
case where there are *no* features in the datastore.
But a more generic solution would more appropriate in the long run, don't
you think?

Regards,

--
Damiano Albani

Andrea_Aime4 · January 23, 2014, 11:57am

On Thu, Jan 23, 2014 at 12:45 PM, Damiano Albani
<damiano.albani@anonymised.com>wrote:

On Wed, Jan 22, 2014 at 12:37 PM, Andrea Aime <
andrea.aime@anonymised.com> wrote:

Yes, that's an idea. Mind, the "whole area application to reference
system" is something that is sometimes not known by GeoServer,
and there is no API that you can use to get it, when GeoServer can
extract it from the EPSG database.
So it would have to be something your application knows instead.

While we're on this topic, have you considered providing a REST interface
to the EPSG database available to GeoServer?
There's this "SRS List" page in the "demos" section that resembles what
I'm talking about.
Then in my case I would use the field "Area of validity" as the bounding
box in the case of empty datasources.

Yes, considered it, would like to have it me too, but haven't found a
project to work on that needed it so far.

I also would like to come back to what you said initially:

On Tue, Jan 21, 2014 at 5:29 PM, Andrea Aime <andrea.aime@anonymised.com
> wrote:

GeoServer does not have a way to dodge the values contained in the
headers and do a manual scan.
It would be possible to implement it though, but it would have to be
optional, scanning thorough large
data sources can take ages (as in hours, and during that time, the admin
interface is locked)

I've just discovered that there exists a REST API that provides a
"recalculate" option<http://docs.geoserver.org/stable/en/user/rest/api/featuretypes.html#recalculate>for vector layers.
Unfortunately, even fiddling with the various options listed in the doc, I
haven't been able to trigger the calculation of the bounding box based on
the actual features.
Shouldn't it be the proper way to run this "manual scan" that you
mentioned above?

No, it's too expensive, besides the small data set case, so it cannot be a
default behavior.
Given that REST config is a tool for administrators, I would not be against
having an extra option to force the full scan thought. Patches welcomed

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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