[Geoserver-devel] DataStores serving features/maps depending on scale

[Theodor_Foerster]

Hi,
I am not really sure, if this is actually possible. I am looking for a
mechanism, to get the scale (BBOX and MapSize) from a GetMap request at
the dataStore level. The query object, which the datastore receives in
getFeatureReader() only provides the BBOX. A temporary workaround is to
assume always a fixed mapSize.

Thanks for any hints.

Theodor

ITC, Enschede
Department of Geo Information Processing PO. Box 6 7500 AA Enschede the
Netherlands
International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[jive]

The official line is to make the scale (and dpi) into environmental variables (a section of the expression handling that we have not supported yet; because we are waiting for someone like you with a real need). You can then use the environmental variables a little bit like a literal; the get map code would set up these things (and possibly pre-process the expression) before sending it over to the datastore.

The unofficial line is:
- Transaction hint
- Query hint

Cheers,
Jody

Hi,
I am not really sure, if this is actually possible. I am looking for a
mechanism, to get the scale (BBOX and MapSize) from a GetMap request at
the dataStore level. The query object, which the datastore receives in
getFeatureReader() only provides the BBOX. A temporary workaround is to
assume always a fixed mapSize.

Thanks for any hints.

Theodor

ITC, Enschede
Department of Geo Information Processing PO. Box 6 7500 AA Enschede the
Netherlands International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

[Andrea_Aime3]

Theodor Foerster ha scritto:

Hi,
I am not really sure, if this is actually possible. I am looking for a
mechanism, to get the scale (BBOX and MapSize) from a GetMap request at
the dataStore level. The query object, which the datastore receives in
getFeatureReader() only provides the BBOX. A temporary workaround is to
assume always a fixed mapSize.

Thanks for any hints.

There is no way at the moment. What do you want to do, provide a smart
generalization inside the datastore? We could roll out a query hint
that provided a generalization distance hint.

Cheers
Andrea

[Andrea_Aime3]

Theodor Foerster ha scritto:

Yes exactly. I would need some of those hints, to configure the
generalization more comprehensively. I have the 1.5.4 geoserver stuff, I
could also switch to the SVN trunk and contribute some code. Anyway, I
would need some hints, about where to start with that codewise.

Well, all of the coding should be make in geotools trunk. Have a look
at how Hints.JTS_COORDINATE_SEQUENCE_FACTORY is used thought the code,
it should give you enough information to roll your own hint.

Also, you'll need to get committer access or provide a patch, and I believe in both cases you'll have to sign a contribution agreement
in order to assign code ownership to OSGEO (this is for legal
protection of the gt2 codebase).

Cheers
Andrea

[Andrea_Aime3]

Theodor Foerster ha scritto:
(can you keep the ml posted as well?)

And those hints will then be automatically generated by the geoserver
(based on the getMap request for instance)? Anyway, sounds great. I will
look into it.

Well, it would not be GeoServer, but the StreamingRenderer class which
is located in GeoTools.
Cheers
Andrea

[jive]

Theodor Foerster wrote:

Hey, that sounds great. But how can I get those hints, when the query/transaction is at the dataStore?
  

Well great is as great does; IMHO query hints is a hack that is getting more and more out of control I would much rather see the datastores fixed one at a time if needed.

Here are the links:
- http://javadoc.geotools.fr/2.5/org/geotools/data/Query.html#getHints()
- http://javadoc.geotools.fr/2.5/org/geotools/data/Transaction.html#getProperty(java.lang.Object)
- http://javadoc.geotools.fr/2.5/org/geotools/filter/EnvironmentVariable.html

You will see we only have one env variable defined right now:
- http://javadoc.geotools.fr/2.5/org/geotools/filter/MapScaleDenominatorImpl.html

That may be the one you are looking for?
Jody

Theoodr

-----Original Message-----
From: Jody Garnett [mailto:jgarnett@anonymised.com] Sent: Friday, April 04, 2008 7:29 PM
To: Theodor Foerster
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] DataStores serving features/maps depending on scale

The official line is to make the scale (and dpi) into environmental variables (a section of the expression handling that we have not supported yet; because we are waiting for someone like you with a real need). You can then use the environmental variables a little bit like a literal; the get map code would set up these things (and possibly pre-process the expression) before sending it over to the datastore.

The unofficial line is:
- Transaction hint
- Query hint

Cheers,
Jody
    

Hi,
I am not really sure, if this is actually possible. I am
      

looking for a
    

mechanism, to get the scale (BBOX and MapSize) from a
      

GetMap request
    

at the dataStore level. The query object, which the
      

datastore receives
    

in
getFeatureReader() only provides the BBOX. A temporary
      

workaround is
    

to assume always a fixed mapSize.

Thanks for any hints.

Theodor

ITC, Enschede
Department of Geo Information Processing PO. Box 6 7500 AA
      

Enschede
    

the Netherlands International Institute for Geo-Information Science and Earth Observation (ITC) Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments,
      

is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.
    

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

--- Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for just about anything Open Source.

http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marke
    

tplace _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.
  

[Andrea_Aime3]

Jody Garnett ha scritto:

Theodor Foerster wrote:

Hey, that sounds great. But how can I get those hints, when the query/transaction is at the dataStore?
  

Well great is as great does; IMHO query hints is a hack that is getting more and more out of control I would much rather see the datastores fixed one at a time if needed.

I don't understand how the coordinate sequence hint can be "fixed" in
the datastores. Can you enlighten me?
Cheers
Andrea

[jive]

Andrea Aime wrote:

Hey, that sounds great. But how can I get those hints, when the query/transaction is at the dataStore?

Well great is as great does; IMHO query hints is a hack that is getting more and more out of control I would much rather see the datastores fixed one at a time if needed.

I don't understand how the coordinate sequence hint can be "fixed" in the datastores. Can you enlighten me?

For suppling factories (like for the creation of coordiante sequence or geometry) Hints is okay; it is acting like a poor mans really complicated container - and doing a good job. The part I really like about Query hints is a datastore advertising what is supported - something I think we should do for Query as well (since we do have datastores that suck we may as well admit to that at runtime - and publish filter capabilities information at the same time).

In this case we are wiring up the application so we can accomplish something very specific (say making it create Pojos).

When we start to use Hints to avoid deciding on an API I get worried; START_INDEX, FORCE_2D, FEATURE_DISCONNECTED, LOOSE_BBOX, SCALE, DPI and so on ... all of these change the meaning; or hack around; limitations in Query.

Cheers,
Jody

[Theodor_Foerster]

Where would be such hints initialized? I think, geoserver will be in
charge of that, correct?

Theodor

-----Original Message-----
From: Jody Garnett [mailto:jgarnett@anonymised.com]
Sent: Friday, April 04, 2008 9:03 PM
To: Andrea Aime
Cc: Theodor Foerster; Geoserver-devel
Subject: Re: [Geoserver-devel] DataStores serving
features/maps depending on scale

Andrea Aime wrote:
>>> Hey, that sounds great. But how can I get those hints, when the
>>> query/transaction is at the dataStore?
>> Well great is as great does; IMHO query hints is a hack that is
>> getting more and more out of control I would much
rather see the
>> datastores fixed one at a time if needed.
> I don't understand how the coordinate sequence hint can be
"fixed" in
> the datastores. Can you enlighten me?
For suppling factories (like for the creation of coordiante
sequence or
geometry) Hints is okay; it is acting like a poor mans really
complicated container - and doing a good job. The part I
really like about Query hints is a datastore advertising what
is supported - something I think we should do for Query as
well (since we do have datastores that suck we may as well
admit to that at runtime - and publish filter capabilities
information at the same time).

In this case we are wiring up the application so we can
accomplish something very specific (say making it create Pojos).

When we start to use Hints to avoid deciding on an API I get
worried; START_INDEX, FORCE_2D, FEATURE_DISCONNECTED,
LOOSE_BBOX, SCALE, DPI and so on ... all of these change the
meaning; or hack around; limitations in Query.

Cheers,
Jody

International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[Andrea_Aime3]

Jody Garnett ha scritto:

Andrea Aime wrote:

Hey, that sounds great. But how can I get those hints, when the query/transaction is at the dataStore?

Well great is as great does; IMHO query hints is a hack that is getting more and more out of control I would much rather see the datastores fixed one at a time if needed.

I don't understand how the coordinate sequence hint can be "fixed" in the datastores. Can you enlighten me?

For suppling factories (like for the creation of coordiante sequence or geometry) Hints is okay; it is acting like a poor mans really complicated container - and doing a good job. The part I really like about Query hints is a datastore advertising what is supported - something I think we should do for Query as well (since we do have datastores that suck we may as well admit to that at runtime - and publish filter capabilities information at the same time).

Ah, you will get no much argument from me there, having a way
to expose capabilities is needed indeed. In my mind a hint is a
suggestion, whilst Query interface is (or should be) an order, and
if you can't respect it, you should throw an exception.
That's where datastore capabilities would come into play: have
a way for client code to defend itself agains these exceptions.

In this case we are wiring up the application so we can accomplish something very specific (say making it create Pojos).

When we start to use Hints to avoid deciding on an API I get worried; START_INDEX, FORCE_2D, FEATURE_DISCONNECTED, LOOSE_BBOX, SCALE, DPI and so on ... all of these change the meaning; or hack around; limitations in Query.

I sort of agree. The trouble is that the set is open ended and growing,
how do you represent that with Query alone? Hints really seems to
be the open ended extension that allows Query to grow without breaking.

Cheers
Andrea

[Andrea_Aime3]

Theodor Foerster ha scritto:

Where would be such hints initialized? I think, geoserver will be in
charge of that, correct?

No, the renderer would. GeoServer has no way to specify hints.
Please, have a look in the code and see how that JTS_COORDINATE_SEQUENCE_FACTORY is used (use your IDE and find all
the places where it is used).
Cheers
Andrea

[Theodor_Foerster]

So the renderer has once in the request/response cycle complete access
to all the request parameters of the GetMap request?

Theodor

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Friday, April 04, 2008 10:23 PM
To: Theodor Foerster
Cc: Jody Garnett; Geoserver-devel
Subject: Re: [Geoserver-devel] DataStores serving
features/maps depending on scale

Theodor Foerster ha scritto:
> Where would be such hints initialized? I think, geoserver
will be in
> charge of that, correct?

No, the renderer would. GeoServer has no way to specify hints.
Please, have a look in the code and see how that
JTS_COORDINATE_SEQUENCE_FACTORY is used (use your IDE and
find all the places where it is used).
Cheers
Andrea

International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[jive]

Andrea Aime wrote:

Ah, you will get no much argument from me there, having a way to expose capabilities is needed indeed. In my mind a hint is a
suggestion, whilst Query interface is (or should be) an order, and if you can't respect it, you should throw an exception.
That's where datastore capabilities would come into play: have a way for client code to defend itself agains these exceptions.

Let me try a *two) wild ideas here (be kind since this is a frustrating topic all around and I don't want to go for another round of datastore conversation about how bad the datastore implementations are).

IDEA ONE

Do what we did for get object by id - break out a new interface that the result of getFeatureSource can implement
- if the interface is supported we can use it; if not we can fake it with a wrapper

IDEA TWO

Make the DataStoreCapabilities data structure that includes:
- FilterCapabilities
- indication's of abilities (even a list of the interfaces available to represent read / write / get object by id / etc... so we can accomplish idea one without doing instanceof checks)
- indication of what parts of Query actually work; for things like reprojection not being supported we can know to wrap on our ReprojectionFeatureCollection around the result

Do either of those work for you?

I sort of agree. The trouble is that the set is open ended and growing, how do you represent that with Query alone? Hints really seems to be the open ended extension that allows Query to grow without breaking.

Two ideas:
- current: more data access interfaces that support different kinds of queries (this is current best practice I guess) for things like get object by id
- origional: feature collection methods that we add (to specific implementations) as needed for things like sort, subList, join ...

Cheers,
Jody

[Andrea_Aime3]

Theodor Foerster ha scritto:

So the renderer has once in the request/response cycle complete access
to all the request parameters of the GetMap request?

Sort of. The renderer does not know at all that is't rendering a GetMap, the same renderer is used in uDig, for example.
Yet, it does receive a MapContext that has the data sources and the
style needed to render them, along with the geographic area and the
picture size. But it does not see other parameters such as the palette
to be used, the antialiasing settings, it does not know if it's rendering an png, a gif, a PDF, or an SVG, nor it does know about eventual extra filters specified in the GetMap because the FeatureSource
it receives already embed that filter.

Cheers
Andrea

[Theodor_Foerster]

However, what do I have to do, if I want to pass also vendor specific
parameters of a GetMap request to the dataStore? Then using the renderer
does not seem to be appropriate. Is there any documentation available
for also extending the GetMap interface of geoserver?

Thanks
  Theodor

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Saturday, April 05, 2008 10:21 AM
To: Theodor Foerster
Cc: Geoserver-devel
Subject: Re: [Geoserver-devel] DataStores serving
features/maps depending on scale

Theodor Foerster ha scritto:
> So the renderer has once in the request/response cycle
complete access
> to all the request parameters of the GetMap request?

Sort of. The renderer does not know at all that is't
rendering a GetMap, the same renderer is used in uDig, for example.
Yet, it does receive a MapContext that has the data sources
and the style needed to render them, along with the
geographic area and the picture size. But it does not see
other parameters such as the palette to be used, the
antialiasing settings, it does not know if it's rendering an
png, a gif, a PDF, or an SVG, nor it does know about eventual
extra filters specified in the GetMap because the
FeatureSource it receives already embed that filter.

Cheers
Andrea

International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[Andrea_Aime3]

Theodor Foerster ha scritto:

However, what do I have to do, if I want to pass also vendor specific
parameters of a GetMap request to the dataStore? Then using the renderer
does not seem to be appropriate. Is there any documentation available
for also extending the GetMap interface of geoserver?

No, there is no such documentation and we have no direct paths to
pass random parameters from the GetMap interface down to the FeatureSource. So far we can modify the filters that do define
the layers, and pass some well known hints (datastore independent ones)
from the renderer to the feature source. That's more or less what
we have.

Maybe if you explain a little better what you want
to do we can devise a plan together.

Cheers
Andrea

[Theodor_Foerster]

Hi,
It is not that important, as it is only research and is only meant as a
proof-of-concept. Anyway, in my architecture, I pass a special ID,
specifying the type of user. Then the dataStore preforms some querying
according to this type of user and the scale of the requested map.
That's it. If this is too much of work, I could just maintain two
separate layers one for user a and one for user b, and the client would
then select the correct layer. That's it.

So if this is too difficult, then I might just use this dirty hack.
However, I guess, that the capability of handling vendor specific
parameters inside geoserver is not that unrealistic? Thus this would be
interesting for geoserver in general, right?

  Theodor

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Saturday, April 05, 2008 3:02 PM
To: Theodor Foerster
Cc: Geoserver-devel
Subject: Re: [Geoserver-devel] DataStores serving
features/maps depending on scale

Theodor Foerster ha scritto:
> However, what do I have to do, if I want to pass also
vendor specific
> parameters of a GetMap request to the dataStore? Then using the
> renderer does not seem to be appropriate. Is there any
documentation
> available for also extending the GetMap interface of geoserver?

No, there is no such documentation and we have no direct
paths to pass random parameters from the GetMap interface
down to the FeatureSource. So far we can modify the filters
that do define the layers, and pass some well known hints
(datastore independent ones) from the renderer to the feature
source. That's more or less what we have.

Maybe if you explain a little better what you want to do we
can devise a plan together.

Cheers
Andrea

International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[Andrea_Aime3]

Theodor Foerster ha scritto:

Hi,
It is not that important, as it is only research and is only meant as a
proof-of-concept. Anyway, in my architecture, I pass a special ID,
specifying the type of user. Then the dataStore preforms some querying
according to this type of user and the scale of the requested map.
That's it. If this is too much of work, I could just maintain two
separate layers one for user a and one for user b, and the client would
then select the correct layer. That's it.

So if this is too difficult, then I might just use this dirty hack.
However, I guess, that the capability of handling vendor specific
parameters inside geoserver is not that unrealistic? Thus this would be
interesting for geoserver in general, right?

For normal datastores, that is, those that are pure data sources, what you're asking is probably not useful. But I guess in your case
the datastore is a processing one, something which in GeoTools is
simply not there, mostly because datastore interface is not meant to do
processing (we're rolling out some processing oriented interfaces
right now btw).

The "chosen path" for geotools is to have some other classes perform
processing, and then have those emit a FeatureSource that you
can evantually glue to xml encoding or map rendering.

Adding a parameter to GetMap is in fact not so easy, since it
requires changing the typesafe class we use to make parameters
travel from parsing to actual map rendering, and create a kvp
parser for it. Using the special "format_options" map you could
avoid that, even if that does not see exactly the best name,
since in you case it would be more of a "data_option".

Once you have the parameter set, you'd have to alter the way
the FeatureSources are set up for each layer, see if one of
them implements a special interface of your own that allows
extra params to be passed in, and in that case cast and pass
the parameters (since the standard gt2 interface does not
have any way to pass those). Or something like that...
Have a look at org.vfny.geoserver.wms.responses.GetMapResponse
to see how the MapContext used by the renderer is built up.

In any case yes, chances are that to pass extra parameters
you'll have to create/modify various classes.

So far we added a few vendor parameters,
but none so far had to talk directly to datastores in a way
that is not built-in into the gt2 interfaces.

Cheers
Andrea