I closed this GeoTools pull request. Andrea's email helped me realize that this
change is not needed. Thank you Andrea.
I also need to update the GeoServer pull request accordingly.
Thank you,
Jeffrey Wood
Software Engineer
Geocent
Email: [email protected]<mailto:[email protected]>
Ph (BR): 225-214-4346
From: [email protected] [mailto:[email protected]] On Behalf Of Andrea
Aime
Sent: Saturday, November 09, 2013 7:35 AM
To: Jeffrey Wood
Cc: [email protected]
Subject: Re: [Geotools-devel] Feedback requested - for pull request #305 - Add
hint property (Map<String, String>) to GeneralParameterValue interface and
AbstractParameter which implements it.
On Mon, Nov 4, 2013 at 6:20 PM, Jeffrey Wood
<[email protected]<mailto:[email protected]>> wrote:
GeoTools developers,
Per Andrea, I am writing to this list re: our proposed change to the GeoTools
public interface. We are proposing a change to the GeoTools
GeneralParameterValue interface and the class that implements it,
AbstractParameter, to add a property that is a Map <String, String>.
Why add this property?
To support our GeoServer change to let users set the layer's elevation
dimension default value. Currently, GeoServer does not look for any layer
input, it decides for itself to use the minimum numeric value. We need a way
to transport the layer specific value, and the way we saw to do that is to
provide it through the 'merged' parameter. If it is not provided, GeoServer
uses its existing method.
Honestly I don't see why this is needed. When a default parameter is chosen the
GeoServer code should be already stating explicitly, to the
reader, which elevation/time value it wants, using the default in case none was
provided.
So why do we need an extra hint along the parameter?
Why a Map?
We did not want to make it a named property, we instead wanted to make a single
Collection that could hold this layer attribute and any other layer attributes
without further changes to the GeoTools entity. So we propose a Map<String,
String> and the user can look up the value they are interested in.
Yes, this is an approach we have in a number of other places and I guess it's
fine... just don't get why you need it in
the first place, see above.
As a general observation, when discussing an API change you should not just say
why it's needed for you, it immediately
makes the change look special purpose, explain instead why the change is useful
in general, and then make an example
with your use case. That is, show why it's good for GeoTools, not why it's good
for you :-)
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
-------------------------------------------------------
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
