GeoTools : 2004-10-18 October 18th

<jive> hi everyone
<cholmes_> Here they are. Let's get started - agenda?
<jive> Just struggling with parameters w/ david - did not see the time go by
<jive> Well there is lots of stuff
<jive> I am away for a month so I would like some volunteers to cover for me
<jpmeagher> 1) Feature Type ancestors
<jive> Hi Jesse they are just setting up an Agenda.
<jive> 2) Data Access
<jive> 3) 2.0 status?
<aaime> brb
<jive> Well lets start -
<jive> 1) FeatureType ancestors?
<jive> What is up? And you you mean in FeatureType "superclass" or FeatureCollection parent?
<jpmeagher> I'm working on the Annotations as discussed on the dev mailing list a few weeks ago
<jpmeagher> I defined a FeatureType Annotation
<jpmeagher> it has an attribute
<jpmeagher> I use that as the "superclass" for a certain VPF feature type
<jpmeagher> When I try to build the actual feature via the create method there is no way to pass in the
attribute for the "superclass"
<jpmeagher> It throws a schema exception
<jpmeagher> Trying to manually set the attribute also fails
<jive> You are using DefaultAttributeType?
<jive> Time to make your own ...
<jive> chris may join you - he wants to allow for nested attributes.
<jpmeagher> Actually it's the DefaultFeatureType that's causing the problem, not the attribute type
<cholmes_> Do you have a solution to fix it?
<jive> Understood - same suggestion NonDefaultFeatureType
<jpmeagher> It needs to do something to search through the ancestors list of types to find the list of
allowed attributes
<jpmeagher> I can solve it for the setAttribute call, but not for the feature type create method
<jive> cholmes_ is more familliar with this then me - any suggestions chris?
<cholmes_> It's been a long time since I've thought about this stuff...
<cholmes_> I can probably take some time this week to look at it...
<jpmeagher> I've got time to spare to fix this also, let me know if I can help
<cholmes_> Ok, shoot me an email summarizing the problem, and maybe a sample file/use case.
<jpmeagher> will do
<jive> Is that sufficent guys?
<jive> This is a solvable problem?
<jpmeagher> I think so
<jive> cool.
<jive> I think we may want to do 3) 2.0 release status next ...
<cholmes_> James hit huge problems at work.
<cholmes_> I think he's swamped till wednesday
<jive> I kind of used up my slack volunteer time last week - this is probably up to you chris/james.
<cholmes_> I'm on dial-up, though on my computer I think I managed to download his latest sample source
file, but I haven't tried it yet.
<cholmes_> Yeah, we'll get it out this week.
<polio> maybe we should address whether we think it is ready for a full release
<jive> Well rueben found and extra module he did not want us to include.
<jive> Other than that we have "buy in" for all the module maintainers.
<polio> ok, just wanted to make sure
<jive> It is the best Geotools 2.0 we have ever made after all (smile)
<jive> My only concern is Jira issues against 2.0 - everyone (myself included) has fallen behind.
<cholmes_> I think it's fine for 2.0
<cholmes_> We should just get better about doing it right on 2.1
<polio> only 4 issues against 2.0
<polio> SDO Polygon Hole Encoding & Exception Handling is the only one i'm concerned with
<jive> (and that is me :-p )
<polio> there are 2 maven ones (which won't matter after the release) and a release note from jody
<polio> when that's fixed, i can up the jars
<jive> I am still waiting for a thest on GEOT-239 - I would like to assume it worked :-P
<jive> I am going to go ahead and perform the fix on Multipolygon encodings ... I just ask that someone
test 2.0 oracle support before it goes out.
<cholmes_> I can install oracle and give it a go.
<jive> Okay, that would be good - I am going to be pretty stretched for time this week.
<jive> Anything else you need for 2.0 relase Chris/James?
<polio> next?
<jive> 2. Data Access
<jive> By way of introduction this is an evolutionary change (rather than last years undertaking).
<jive> Right now AbstractDataStore supports Catalog, we are looking at making that explicit. The other
thing on the books is choosing one Parameter solution and running with it.
<jive> If you go to the bottom of: http://docs.codehaus.org/display/GEOTOOLS/Data+Access
<jive> You can see the complete list, and a few proposals throughout the document (like simplifying
CatalogEntry to have a Map of Metadata)
<polio> I started a few interfaces ...
<jive> I would love to do this work - it will be fun - but I am heading off on holiday and David is given
the nod.
<jive> Over to you david ...
<polio> I striped them of comments to avoid confusion with the old comments, and added/deleted methods
where appropriate
<polio> http://svn.geotools.org/geotools/trunk/spike/dzwiers/
<jive> David maybe you could go through the list in order?
<polio> two biggest changes is the importance of Catalog in the new version, and the use of the factories
(should create singletons for a param set)
<polio> creation: find and create access from a single param with sensible defaults
<cholmes_> Where is Catalog?
<polio> everything is either a Catalog or CatalogEntry untill you get to a FeatureSource
<jive> Second section in http://docs.codehaus.org/display/GEOTOOLS/Data+Access
<cholmes_> the code?
<polio> GeoApi
<jive> Or http://svn.geotools.org/geotools/trunk/gt/module/main/src/org/geotools/catalog/AbstractCatalog.j
ava
<cholmes_> ah
<jive> It is an interface...
<polio> GridCoverages would be accessed in a similar way to feature data ... infact with the similar
apram the goal is to find either grid of feature data from a url
<jive> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/catalog/Catalog.html
<polio> FeatureSource has been extended to include random access, as has FeatureWriter. There is also an
additional index interface which is optional.
<jive> Note AbstractDataStore implements Catalog right now - basically a CatalogEntry for each
FeatureType, getResource() produces a FeatureSource ....
<polio> actually FeatureStore (not FeatureWriter)
<polio> We have kept the FeatureReader/FeatureWriter and GridCoverageReader/GridCoverageWriter the same
(minor changes for grids) to use the existing well tested code
<polio> these have been removed from the high level api, and will be used in abstract implementations
<jive> I have been volunteered to make some pictures (time to download omondo again )
<polio> The catalog relation to the proposed api will be more aparent when Jody completes the diagrams
<jive> Okay so is that the most important recomendations?
<polio> yup
<polio> I was hoping for feedback mid week, and some talk about where development should occur. If we
have substantial 'buy in' I was thinking of head, otherwise a branch may be more appropriate
<jive> I will certaintly review this before I go (so by wednesday), giving a chance for a revision while
I am still here.
<jive> Now last time we got a bunch of great feedback from Chris and Rueben.
<jive> Just a couple of days after we did our design session. Is their anything we can do differently
this time?
<jive> Should we try for a breakout IRC or something? What would people like to do?
<aaime> Don't know... consider me off the project for one month at least... I'm too loaded on work wise
and spare time wise...
<jive> Okay, too bad, but understood.
<jive> (sad)
<polio> doh
<jive> Reminds me about the FIDMapping issue david - not that we can fix everything in one go.
<jive> So far I see three proposed changes that would ripple through the API:
<polio> yah, havn't put alot of thought into that, but once again it can be partially resolved with the
QueryAs stuff
<aaime> I was hoping to work on gt2 when I get back from work, since I can't do it anymore during spare
time. But I'm too tired when I get back home. And besides this, there are no small things to do...
everything is needed is quite a big effort...
<aaime> (spare time being weekends)
<jive> Yeah - I choose the worst time to go on holiday (smile)
<rschulz> One question - will the featureStore/Source/Results thing be simplified (if possible?)
<jive> Change 1) FeatureReader and Writer used restricted to low level access - File and Stream? This
would just mean that Database DataStores do not have to implement FeatureReader/FeatureWriter unless
needed?
<polio> yes it has been ... there are not any featureResults anymore
<polio> correct jody
<jive> Change 2) Creation Param is looking to get an overhaul, making a Factory responsible for keeping
things as Singletons is a change (impelmentators would need an example)
<rschulz> nice, that will decrease confusion
<jive> Change 3) FeatureIterator used rather than FeatureReader by high-level api.
<jive> This would break a lot of rendering code. FeatureReader had strong close support.
<jive> I am not sure FeatureItterator is up to the task?
<polio> http://svn.geotools.org/geotools/trunk/spike/dzwiers/src/org/geotools/data/feature/FeatureIterator
.java
<polio> it was meant to work in conjuction with FeatureSource
<jive> I really think we need to add close() to that class?
<polio> http://svn.geotools.org/geotools/trunk/spike/dzwiers/src/org/geotools/data/feature/FeatureSource.j
ava
<polio> think you may have raised a good point there
<polio> just wondering if that's part of the FeatureIterator or the FeatureSource that creates it
<polio> was trying to remove access to the FeatureType everywhere, restricting the access
<polio> (basically I though you should know what you were asking for already ... so no need to ask for it
back)
<jive> Perhaps you could make the change to FeatureReader - remove getSchema() ?
<polio> though about that too, but wanted to keep all the low-level apis the same to avoid re-writing the
code ... it's well tested
<jive> Note - for files reading the Header to figure out the type is often the first thing done with the
open file?
<jive> Is their anyway to know the FeatureType without performing this step?
<jive> Although one thing I like about FeatureIterator not having the schema is it would allow access to
a GML Document with lots of different kinds of FeatureTypes...
<polio> it leaves more options for the implementors ... but yes in that case the implementator would
cache the parse which had begun, and finish it in a later request
<jive> I wonder if FeatureReader can extend FeatureItterator?
<polio> yes
<jive> That would work out quite nicely then...
<jive> Well that is change number 3 ...
<jive> Is this useful for everyone?
<jive> I can have design discussions with David offline, or we can call a breakout IRC session on this?
<jive> I think david was asking for a review and then a vote for him to work on a branch or head?
<jive> So it seems we are bit short on man power for this task ... as productive as David can be.
<polio> the problem with a branch is that it would be hard to merge bug fixes in ... fairly major change
here, but then that's also the risk for head
<polio> to do this efficiently we need a group of people, each person to tackle one/two datastores and
then it could be completed quickly
<jive> One stratagy is to make a new AbstractDataStore that does everything based on
FeatureReader/FeatureWriter - and then just cut over the DataStore implementations (this is what I
would do).
<jive> I would feel more comfortable reviewing this API if we had a toy "Memory" implementation to play
with and kick the tires.
<polio> yes, I though about that, but we would still need to worry about the smart implementation, such
as postgis
<jive> Well the toy would let people evaulate if it works well as a client API.
<jive> i.e. What we are looking for is feedback and buy-in - and everyone is quiet and busy (smile)
<polio> we've babled on for 30min ... if people have comments or suggestions perhaps the email list would
be better
<jive> Well david I will review on wednesday, we can actually write this up as a proposal for people to
read on the weekend - and vote on next monday.
<jive> I am still in the country next week and can read some email in the evenings.
<polio> ok, we can try
<jive> Any other agenda items?
<aaime> I'm sorry for not actively following the discussion but
<aaime> another set of changes gives me headache.
<rschulz> Ok, my only comment is that the project may not have resources for a change this big
<rschulz> It may need to wait for people to come back from holidays/work
<aaime> We have been revolving around arch changes for one year now... and I see nothing getting out.
Hopefully udig will change that...
<jive> Can we try and narrow scope?
<jive> Well this is the first round of UDIG inspired changes - we cannot use the Parameter model as laid
out now.
<Martin_> Which changes do you need to Parameter?
<aaime> As you can see I'm putting high hopes on udig... but it's really my last hope on gt2 for the
client side (smile)
<jive> David was starting this ball rolling so he could work on Schema modifications (he is willing to
give up and work on something else)
<jive> Part of the creation problem is keeping DataStores as singletons
<aaime> If you feel they are needed, they are needed. I only hope this is the last heartquake...
<jive> Right now UDIG tries to do that by using a Map of Params -> DataStore
<aaime> (earthquake, sorry)
<jive> (but Shapefile memory mapped true <> Shapefile memory mapped false)
<jive> earthquake?!
<jive> ah
<jive> Me to - but we have known limitations to parameters since last January; this is the first time
anyone has budget and a need to fix them.
<Martin_> Jody, is it related to org.geotools.parameter? If so, which change do you need?
<jive> The Catalog work is the same deal; I have tried three times already. The current idea works
(AbstractDataStore implements Catalog) - this is just making that relationship part of the API.
<jive> Not really related to org.geotools.parameter martin - it a data modeling problem.
<jive> What parameters model identity, what parameters model configuration?
<jive> The really issue keeping a DataStore as a singleton for all access to/from a given noun
(shapefile, server, wms)
<jive> David can we cut scope and still do you Schema manipulation?
<polio> I went to make a Datastore, and was forced to make low level things that are not required ... and
had to sub-class an un-maintainable class ...
<polio> In the longer term, I don't think adding more functionality over an already un-maintainable
interface is worth my time. I would rather make the interface plausable
<jive> I would like to clean up the duplication, DataStore is in better shape the GCE? Perhaps if we did
DataStore now (less work) and GCE later we would have something?
<polio> I would not recommend to my employers that I spend more time working with AbstractDataStore in
it's current state
<jive> I was already planning on cleaning it up, is it something I should fix before I go David?
<jive> JDBCDataStore already maintains an internal object for each Table.
<jive> That is what I need at the AbstractDataStore level.
<polio> it has to do with all the changes with the api ... low-level mixed with high level apis, and
catalog thrown in halfway through the mix
<aaime> Going... bye all...
<jive> I am lazily making wrappers right now (a CatalogEntry that wraps a typeName)
<polio> later
<polio> you should not have to make 3 wrappers for one piece of work + extend an abstract class to build
a datastore. Adding more functionality to this would not prove fruitful in my opinion.
<polio> rather we would have more wrappers, and levels of indirection
<jive> I am not sure I understand.
<polio> imagine writing low-level apis to work with data type declaration in a generic way. The code
would be worse than spageti
<Martin_> One other topic (if you have time). On org.geotools.parameter, I have 2 questions (for Jody)
<polio> I think what we need is a clear distinction for data access between high and low level apis.
Basically the most important change here is spliting the high level and low level to make the api's
manageable. Allowing people to create one or the other, accepting there contributions, and not forcing
there hand.
<jive> Sorry martin we are all a bit discouraged today.
<Martin_> What happen?
<rschulz> They are proposing another DataStore api change.
<rschulz> It will make things nicer, but will be lots of work and create a lot of pain while things are
changed
<Martin_> I tend to be all for nicer API, but you guys are the one to ask for DataStore API...
<polio> short version is incorporating Catalog with the DataStore api, and removing the low-level
portions of the api from public view (for implementors who want magic only)
<Martin_> Do we have a few minutes for 2 quick Parameter small issues?
<jive> Okay I will trade you for a J2D question.
<jive> Shoot.
<Martin_> first question: do you have any problem if I move the ParameterValueGroup.add(GeneralParameterVa
lue) functionality from ParameterValueGroup to ParameterValueGroup.values()?
<Martin_> I.e. instead of writting:
<Martin_> group.add(param)
<Martin_> you would write
<Martin_> group.values().add(param);
<Martin_> Advantage: Make the add(Parameter...) method less visible from ParameterGroup (I would like to
not encourage its use too much)
<Martin_> And 2: more functionality (you can invokes addAll, remove, etc.)
<Martin_> The group.values() List would be a special implementation linked to the ParameterValueGroup it
come from.
<Martin_> ?
<jive> you did suggest this before, the same anser as last time - you are making implementing this much
to hard. It has gone grom implementing a simple API to implementing a simple API (ParameterGroup) and a
hard one (List).
<polio> later all
<Martin_> I don't agree. Implementing lst on top of AbstractList IS easy. Basically, you only have to
override the get and add methods; everything else is handle by AbstractList. The add method who just
redirect its call to ParameterValueGroup.add
<Martin_> So this IS easy to implements, with a cleaner API it seems to me.
<jive> Could we have ParameterGroup extend List then?
<jive> <grin> my origional proposal
<jive> i.e. why force them to implement two things?

  • polio has left #geotools
    <jive> .. backs off ...
    <jive> What you propose does work -
    <Martin_> I would not feel confortable with that. To me a ParameterGroup is not exactly a list. It
    contains a list however.
    <Martin_> java.util.Map is not a Set. It contains a Set however (Map.entrySet()).
    <jive> Yeah I get it.
    <Martin_> This ParameterValueGroup.values() paradigm is similar to Map.entrySet() to me...
    <jive> Thinking hard ....
    <jive> I think we disagree a bit on the visiability of Groups. To me they are the one thing
    ParameterGroup does really well.
    <jive> Making a optional "authorization" parametergroup of (name and password) is going to be one of the
    main things people do with parameters.
    <Martin_> What means "visiability", and what is the issue with "authorization" parameter group (it seems
    to me they can be handle as well with both approach)?
    <jive> just a sec ...
    <jive> You said above that you did not want to encourage ParameterGroup
    <jive> ie make it visiable.
    <Martin_> No!
    <jive> ah
    <Martin_> I don't sais that I don't want to encourage ParameterGroup!
    <Martin_> I would like to not encourage ParameterGroup.add(GeneralParameterValue) method!
    <jive> okay - I think I am understanding.
    <Martin_> Because I would like to lets ParameterValue construction to be controled by the implementation
    as much as possible.
    <Martin_> (rather than putting it on the user side).
    <jive> This is a tough issue, because for the DataStore construction case we won't know the
    implementation until we have parameters to go hunt it down.
    <Martin_> Thats said, if a user really want to constructs ParameterValue himself, he still can do.
    <jive> So what the change you propose would do is make the construction of multiple groups difficult.
    <jive> But still doable.
    <jive> The benifit is a simplified api.
    <Martin_> If you don't know the implementation, then isn't one more argument for letting thel ibrary
    construct the parameter value itself rather then the user?
    <Martin_> No, I don't propose to make construction of multiple group difficult!
    <Martin_> Quite the opposite! I the use case I can imagine, the proposed API would be simplier to use
    and, if I'm right, safer.
    <Martin_> Instead of the following:
    <jive> Okay martin perhpas we should do a code example
    <jive> (sorry to be so slow on this martin - it has been a while)
    <Martin_> A code example would help.
    <Martin_> Please send on the mailing list an example of the way you use ParameterValue, and I will send
    back the way I propose to use it.
    <Martin_> (for the same task)
    <jive> Okay I can do that (smile)
    <Martin_> My second (and last) question then:
    <jive> While I type that up can I ask you about J2D renderer.
    <Martin_> Sure (smile)
    <jive> I just ask because Jesse is going to start on optimization soon, we have been using LiteRenderer
    and would like to start optimizing it.
    <jive> Or starting a discussion with both of you about turning optimizations into stratagy objects for
    reuse.
    <jive> Or something (smile)
    <jive> Perhaps you should tell us what we should ask you (smile)
    <jive> (I am going to go back to trying to write a small example now)
    <Martin_> I would have loved to port J2D renderer to make it more usable for Geotools. There is so many
    work in it, if we end up doing the same work in lite-renderer, it may be more work than refactoring J2D
    renderer.
    <Martin_> I'm volunter for doing it, but
    <Martin_> I need to finish CRS refactoring first,
    <Martin_> next I need to finish GridCoverage refactoring,
    <Martin_> next GridCoverageExchange...
    <Martin_> Only then I would be ready to attack J2D renderer (sad)
    <jeichar> The thing is that I need a renderer now.
    <Martin_> As far as I know, J2D renderer have two problems:
    <Martin_> 1) Store all data in memory, so we can't display huge file for now
    <Martin_> 2) Styling is not as elaborated than lite-renderer.
    <jeichar> Right.
    <jeichar> and it is pretty complicated for some one else to contribute to.
    <Martin_> Would it be a big problem if 1 is fixed only in, said, 4 months?
    <Martin_> Well, maybe 6 for not making false promise.
    <jeichar> I'm afraid that I need something efficient really soon. It is my job to do that starting now.
    or maybe next week.
    <jeichar> I'd like to use j2d because it is fast.
    <Martin_> J2D renderer as much more work in it than lite-renderer on the optimisation side, and some of
    them was really hard work.
    <jive> Sent out param example
    <jeichar> I agree
    <jeichar> that is why I want to use it as much as possible. Is there any way to combine them?
    <Martin_> I have never worked on styling for J2D; this work was done by Andrea.
    <jive> Hi again marint
    <jive> martin - bad typo
    <Martin_> Pieces can be reused, but you will endup basically redoing J2D renderer.
    <jive> Did you guys think about refactoring the j2d optimizations as stratagy objects?
    <jive> Ah I see you are doing scheduling.
    <jive> Jesse has two months I think to work on rendering a performance .... first question is would you
    like us to work with J2D martin?
    <Martin_> For example the whole org.geotools.renderer.geom package can be use independently of
    org.geotools.renderer.j2d.
    <Martin_> Sure I would like it (smile)
    <jive> You have lots of great ideas that we would like to reuse, but we don't want to thread on your toes
    either (sad)
    <Martin_> For now I'm quiet on rendering side, since I'm focussed on CRS.
    <jive> Great - my best plan so far involves breaking it down into understandable bits - this would allow
    lite renderer to reuse pieces as well.
    <jive> The main point is to allow the rendering pipeline some flexability depending on data turnaround
    (WMS vs local Shapefile for example).
    <jeichar> Just to go back to Jody's suggestion. Can J2D be separated into strategy like pieces?
    <jive> What do you think? And I wish Andrea was here (don't want to tread on his toes either).
    <jeichar> So they can be added or removed depending on the situation?
    <Martin_> There is already some of such pieces.
    <Martin_> An important one is org.geotools.renderer.array package.
    <Martin_> Actually, if you are up to work on it, there is my proposal.
    <jeichar> Sure, propose away.
    <Martin_> (it is work I planned for a long time, but didn't had the time to do).
    <Martin_> 1) org.geotools.renderer.array package can been seen as an implementation of
    org.opengis.spatialschema.geometry.PointArray interface.
    <Martin_> So first step: Move org.geotools.renderer.array package into org.geotools.geometry.array. Make
    it implements PointArray.
    <jive> Ah Martin this is where you start to lose us (smile)
    <Martin_> (this way we are going toward ISO 19107)
    <Martin_> Okay, I will explain it in other words.
    <jive> Jesse I think he is talking about the objects he uses in his Cache? ie a Go-1 Graphic ?
    <Martin_> One very important piece of
    <Martin_> (oups, send too early)
    <jeichar> yes I'm following him so far.. I think.
    <jive> Is it worth thinking about these in Go-1 terms martin?
    <Martin_> GO-1 if we can, but we can also thing a little bit in term of ISO 19107.
    <Martin_> In my understanding, GO-1 = ISO-19107 + Styling. Is it right?
    <jeichar> ok give us the proposal and we can discuss it after ok.
    <jeichar> that's right
    <Martin_> One very important piece of J2D optimisation is the special geometry implementation is uses.
    <Martin_> Those geometry implementation has no styling information, so it is not yet GO-1 object. It is really just
    that: geometries, but with special methods for decimation, reprojection, etcOne very important piece of J2D
    optimisation is .
    <Martin_> Those implementation can be refactored as ISO 19107 objects (I think it will not be too difficult).
    <Martin_> In ISO 19107, the internal data of a geometry is described by a PointArray.
    <jeichar> ok
    <Martin_> J2D renderer defines a PointArray class too. Again, very slight refactoring would be needed to make J2D
    PointArray implementation a real GeoAPI PointArray implementation.
    <jive> Okay for me too.
    <Martin_> In J2D renderer, PointArray wrap an arbitrary array. It can be a float[], it can be a JTS's
    CoordinatePoint[], it can even be a ZIP file (smile).
    <jeichar> These are cached in J2D right?
    <Martin_> For now, only float[] and JTS's CoordinatePoint[] are wrapped.
    <Martin_> Yes. But caching is not PointArray's job. PointArray is nothing else than a layer of abstraction over the
    real underlying storage scheme.
    <jeichar> yes I understand
    <Martin_> So part of the solution of memory consumption lies exactly there: we could very well write an other
    PointArray implementation fetching data directly from disk (smile)
    <jeichar> I see...
    <Martin_> But anyway, as a first step, I would propose to move org.geotools.renderer.array package into
    org.geotools.geometry.array and implements the ISO 19107 interface.
    <Martin_> Then move org.geotools.renderer.geom package into org.geotools.geometry.(something) and implements ISO
    19107 interface as well.
    <Martin_> Then write GO-1 object which would contains a renderer's geometry + styling information.
    <Martin_> Note that up to this point, all this work could be used by lite-renderer as well...
    <jeichar> j2d doesn't use GO-1 object. wouldn't it be a lot of work to incorporate those interfaces or no?
    <Martin_> Note that renderer's geometry can easily wrap other arbitrary ISO 19107 implementation. This is just a
    matter of writting the right PointArray implementation, which should be pretty straightforward.
    <Martin_> J2D doesn't use GO-1 object yet, but I would like it to use it. Not sure yet how much work it would be.
    <Martin_> I don't think it would be much work actually. Styling is pretty weak in current J2D implementation, and
    styling is what GO-1 object bring.
    <Martin_> (compared to ISO 19107).
    <jeichar> ok. So how would we be able to incorporate the org.geotools.geometry.(something) geoms into Lite? or
    other renderers for that matter?
    <Martin_> lite-renderer should not renderer JTS geometries. They should renderer ISO 19107 geometries instead.
    <jeichar> Does J2D handle all the feature loading?
    <jeichar> And the implementation of the ISO 19107 geometries would be read from disk once created.
    <jive> I think it goes Feature.getDefaultGeometry -> org.geotools.Geometry (a java Shape backed by Pointlist) ->
    screen?
    <Martin_> J2D renderer do nothing special with feature loading. It has no knowledge of DataStore actually.
    <jive> So I think we need to combine the best of both worlds ...
    <Martin_> I was thinking about implementing feature loading at the lowest level, right in a special PointArray
    implementation.
    <jive> Note if Martin Davis JTS back by float change is made available to use we may be able to use use the same
    PointArray in JTS as we use in org.geotools.geometry.
    <Martin_> I'm not sure it is the right level (since I have not really looked at this yet), but it would allows a
    very fine grain loading.
    <jive> We can probably load them at that level from a shapefile ...
    <jive> Martin is there any high level documentation on J2D?
    <jive> I know Jesse wrote up something ...
    <Martin_> They were a quick introduction (very incomplete) in french sent a few months ago... I don't have an other
    one at this time.
    <Martin_> But if you start the work on PointArray, before to switch to geometries, it would be a gentle
    introduction which would also have the advantage to be usable for something else than J2D renderer.
    <Martin_> PointArray should not be difficult to understand.
    <jive> Apprently Jesse already understands it (smile)
    <Martin_> Nice (smile)
    <Martin_> So what is yours decision?
    <jeichar> Some what, I'm not an expert.
    <jive> So we have to several places to optimize - The reading/streaming from disk/datastore, the conversion from
    JTS/to java Shape, the merging of layers.
    <jive> Is that about right?
    <jive> Well I would like to talk to Andrea as well (there are two renderers and we should try and facilitate code
    reuse).
    <Martin_> This is mostly the reading from disk/datastore.
    <jeichar> That is my biggest concern. I like the simplicity of Lite and the performance of j2d.
    <jive> Andrea had some good ideas about how to read from disk in the correct format (despite JTS
    CoordinateSequences).
    <jeichar> If we can transform j2d a little. Like what martin said.
    <jeichar> I think that is a good start.
    <Martin_> I realize that the complexity of J2D renderer is too complex; this is exactly the reason why I would
    really like to transform it the way I said (broke it in more obvious part, put it in conformity with more
    standard so the API appears less foreigner to other developper...)
    <jeichar> exactly.
    <Martin_> If you don't start this work this week, we can come back on this issue at the next IRC meeting.
    <jive> I think Jesse starts next week
    <jive> (I won't be here though).
    <jeichar> I won't have time this week or next week.
    <Martin_> (note: transforming J2D like I said is really something I would like to do).
    <jeichar> not next week jody, I'm at OOPSLA next week.
    <jive> right
    <Martin_> Okay, so we have a little bit of time to though about it before any work start.
    <Martin_> Before to leave, I have my last question about Parameter (I admit it is a minor issue):
    <Martin_> Parameter and ParameterGroup are currently the only GeoAPI implementation with a different name
    ("Parameter" instead of "ParameterValue", "ParameterGroup" instead of "ParameterValueGroup", "AbstractParameter"
    instead of "GeneralParameterValue...").
    <Martin_> Most other GeoAPI implementations use the same name. Well, all of them use the same name when there is
    exactly one natural 1-to-1 correspondance.
    <Martin_> Note that I don't claim that it is the right thing to do. But it make the correspondance with GeoAPI
    really obvious without adding the same prefix everywhere if front of each name.
    <Martin_> Should we rename Parameter, ParameterGroup and Abstract* implementation in order to follow this policy,
    so they are not the only one to be different? would it reduce or increase confusion?
    <jive> yeah
    <jeichar> Are you're geometry objects transformed, or do they need to be transformed before rendering?
    <jive> It is hard because the data loading and analyitics need to use JTS at this time. Given how well (not)
    DataStore proposals went over today I really can't see us switching Geometry models anytime soon.
    <jive> Good question: screen coordinates or world coordinates.
    <jive> BTW Martin the parameter group example is on email.
    <Martin_> Geometry doesn't need to be transformed before rendering. Data are transformed automatically at rendering
    time. Actually, only the cached data are transformed, not the whole geometry. This is more efficient than
    transforming the whole geometry since cached data have usually been decimated.
    new geometries? Or does a feature store create the geometries is there yet another way to laod geometries.
    <jeichar> ?
    <Martin_> Renderer's geometry can already wraps JTS geometies. Usage of JTS should not be a problem (appart of
    memory consumption of usage of CoordinatePoint[]).
    <jeichar> Yes. I was talking about what you would like in the future, not what is the case right now.
    <Martin_> In the future, I would like DataStore or feature stores to returns ISO 19107 interfaces instead of JTS
    geometries.
    <Martin_> For creating those ISO 19107 interfaces, the feature stores would use one of GeoAPI factories.
    <jeichar> (smile) a ways in the future though I imagine
    <Martin_> The geometry factory to use could be specified to the feature store.
    <Martin_> A renderer could specify a factory which build its special ISO 19107 implementation, optimized for
    renderer needs.
    <jeichar> I see. Is there support for that now?
    <Martin_> Geometry factories interfaces already exists on GeoAPI.
    <jeichar> ok, I wasn't sure.
    <Martin_> What we need now is ISO 19107 implementation wrapping JTS object. Note that this work is totally
    independent of any renderer work.
    <Martin_> But we will need it in order to apply my suggestion for rendering.
    <jeichar> If made the suggested changes, how could lite use them. I think I might have already asked this, my
    apologies.
    <Martin_> If lite renderer ISO 19107 geometries instead of JTS one, one such ISO 19107 geometries would be the
    refactored J2D geometries. lite-renderer could use the special hook provided in those J2D geometries if it which.
    <Martin_> (with an "if (x instanceof ...)" clause)
    <jeichar> ok. I understand thanks.
    <jeichar> Can we have this conversation again in 2 weeks? I'll have a plan as well by then. Also if you have any
    more ideas, I'd appreciate it if you'd email me. jeichar@refractions.net.
    <Martin_> No problem (smile)
    <jeichar> Any one have anything else to discuss? I'm pretty much tapped out for today.
    <Martin_> For Jody, just my last question about Parameter naming (sent a few lines above)
    <jeichar> ok.
    <Martin_> Is Jody still there?
    <jeichar> yeah. I think he's in the middle of something, he'll be back in 1 sec
    <jeichar> may be not. You might be better to email him the questions unless they're really important, in which
    case I can interrupt him
    <Martin_> No problem. I will go then. Bye all
    rv:1.7.2/20040803]")
    <jeichar> bye
    <jeichar> everyone