Monday, July 26, 2004

 

IRC Logs - July 26th

- geotiff
- modules.geotools.org
- geotools main site
- demos


jyutzler Agenda Items?
rschulz jody and david are at the gml conference
jmacgill ah yes modules.geotools.org (as agenda item)
rschulz 1) someone wanted to discuss geotiff - should tell him about jodys text base CS authority factory
TheSteveMonkey anyone going to the ESRI user conference?
jyutzler 2) modules.geotools.org
jmacgill not me
jyutzler Any other agenda items?
rschulz 3) geotools main site
jmacgill yes indeed
rschulz 4) gt/ext/demos organization
jmacgill slow typing again today, holding rebecca
jyutzler Okay. Let's get started.
1) someone wanted to discuss geotiff - should tell him about jodys text base CS authority factory
rschulz email on the list said he would probably show up here
jmacgill did their code need to go in an extsting plugin or a new one?
rschulz perhaps we should move on until they show up
jyutzler 2) modules.geotools.org James?
jmacgill Rebecca now with mummy.. two hand typing ok, Philip Crotwel has fixed the site generation script so modules.geotools.org is now up and running each day again it includes a page for each module, ext and plugin
jyutzler Cool. Anything else on this topic?
jmacgill The text on each one comes from the description tag in each project.xml file so, update this if you want your module to have a nice description Also, it acts as a sort of automated build test for example http://modules.geotools.org/multiproject/main/junit-report.html#testGetMetadataint shows two fails occured last night http://modules.geotools.org/multiproject/main/apidocs/index.html is the latest javadocs but its only for main
jyutzler So we should probably indicate this in the Developer's Guide...Check the Unit test report...?
jmacgill there is a similar set of javadocs for each module/ext/plugin but I still need to develop a mechanism for merging them yes, that would be good
jyutzler Who can do that?
jmacgill anybody :) the dev guide is wiki based and editable by anyone with an account and anyone can have an account however, I'll do it.
jyutzler By the way, I tried to update the \plugin\vpf\project.xml to give it a (slightly) better description and fix my developer info. When I went to commit, SVN whinged that authorization failed. Would that be because my account is somewhat restricted? I can commit other VPF-related files. Thank you, James.
jmacgill as far as I know we do not have restrictions that are directory or file based it is possible that your copy was not up-to-date
jyutzler I'll try making a trivial change in some other file I've worked with before. I'll also ensure that my copy was up-to-date. I'll deal with this later. Anything else for this topic?
jmacgill only that I encorage module/ext/plugin maintainers to work on minimizing PMC errors (not major, but a nice background task) PMC -> PMD http://modules.geotools.org/multiproject/main/pmd-report.html
jyutzler I agree. In Eclipse, unused imports get flagged as warnings. This is very annoying. It also flags deprecated items, but I guess we are in such a state of flux that I will have to deal with it. Eclipse has a tool that cleans up imports. If there is an appropriate time, we could just run it on the entire code base. Does that interest anyone?
jmacgill watch out for Martin's imports which he uses to make javadoc links work a lot of tools think that they are 'unused' but javadoc fails to create links properly without them
rschulz martin usually flags these with a comment (usually)
jyutzler Hmmm. That is a compelling reason not to use the automated tool. Okay. Let's just try to stick with communication for now. Anything else?
3) geotools main site Rueben?
rschulz I started a page on the wiki (under rnd) with some ideas
rschulz Comments/ suggestions appreciated
rschulz I may have a bit of time to spend on this - once a direction is chosen
jyutzler Noted.
4) gt/ext/demos organization...Rueben again.
jmacgill hang on back to 3 a sec the current main site is xaraya based and I hate it well, not quite true, xaraya is ok, but not for multiple editors and esp as no-one has admin access to the box its running on geotools.codehaus.org is now supposed to have a static cache backup so it should be more stable
rschulz That's good
jmacgill rschultz do you know about the navigation and quicklinks page on confluence?
rschulz How to deal with posting news/ irc logs? yes
jmacgill in which case, feel free to make a start on a better geotools.codehaus page IRC logs are tricky
rschulz ok, the wiki is easier for me to edit
jyutzler How so?
jmacgill a blog entry per IRC might work
rschulz No admin issues (do not need access to server)
jmacgill indeed
rschulz I thought of that james - is it possible to have 2 blogs (one for news)
jmacgill would make sense... also, we can include rss feeds if anyone could host news and irc as rss then that would work
rschulz see http://docs.codehaus.org/display/GEOTOOLS/Blog+test for test rss should be some way to only show first few lines for each entry
jyutzler Any volunteers to host RSS?
jmacgill it should be showing first few lines by default... as for multiple blogs I could setup an extra confluence space that would create a new blog
rschulz also, do you think old irc and news should be ported over?
jmacgill possibly
cholmes_ If it's easy to do then sure, but I don't think it's really worth the effort as long as we archive it _somewhere_
jyutzler This all sounds good as long as we can find someone to host the RSS. I don't think any of us likes having five different websites.
rschulz yes, eliminating the confusion is my modivation for looking into this
jyutzler Ready to move on?
jmacgill yes
jyutzler 4) gt/ext/demos organization
rschulz the demos are located in a number of different directories should they all be put in gt/ext/demos/ ?
jmacgill would gt/demos make more sense?
jyutzler Who would be responsible for moving everything? Or, would it be a gradual thing like moving all of the plugins into the plugin directory?
jmacgill if we come up with a new recomendation then I think it could be a gradual move
rschulz I could move them to get svn practice - do not know how to deal with maven thought gt/demos is ok (then ext can be library code built on top of geotools)
jyutzler Fair enough.
jmacgill propose gt/demos to the list
jyutzler Normally I would recap the agenda items, but I do not think anyone has joined since we started. Anyone else have something they want to discuss?
rschulz no
jyutzler I can copy the IRC log and e-mail it to someone. I don't know who though.
jmacgill me or jody
jyutzler Okay.


Monday, July 19, 2004

 

IRC Logs - July 19th

1) Applogies for breaking the build :-(
2) GML
3) News about GeoAPI telecon (when James will be
back)
4) New module
5) Clean up/out 2.0.x
6) LiteRenderer2


jgarnett G'Day
cholmes Hi everyone! Andrea's going to be 30 minutes late - he's just on to catch the logs right now.
Martin Agenda for today?
jgarnett 1) Applogies for breaking the build :-(
jgarnett 2) GML
Martin 3) News about GeoAPI telecon (when James will be back)
jgarnett 4) New module
jgarnett 5) Clean up/out 2.0.x
cholmes (does anyone here have oracle spatial experience? I'm just finish up an install, and am wondering how to create the spatial tables)
jgarnett chrs: We can put you in touch with Pati (one of the geoserver testers) I am sure she can help.
cholmes cool, that'd be great.
aaime Hello.
aaime Chris, if you create the database with the oracle database wizards and standard configurations, the database will be spatially enabled (provided that you are using Oracle Enterprise 10g as I did)
jgarnett Well I can get item one out of the way.
jgarnett I am afraid that I got a bit confused last week, with the help of Martin and Jesse, and managed to break the build.
jgarnett Sorry for the downtime, I hope everything is back to normal now.
jgarnett Hi James, did you get the agenda?
jgarnett 2) GML
polio I have just made a gmldatastore that streams :)
polio have a bunch of test cases, and currently just putting them into the gt format
jmacgill no missed agenda, can you email it?
polio the streaming uses two threads an a buffer ... and are safe to work concurrently
aaime Hum... that reminds me of something...
polio was talking to james, we were thinking of main for the parser and a module for the datastore
aaime Are you sure using two thread on a single CPU does provide a performance advantage?
polio nope it doesn't, it lets me break into the SAX parser
polio i need a generic way to pause it
jgarnett push vs pull parsing.
aaime I have a feature reader wrapper sitting on my disk that can spawn a thread to do data loading without the upper level noticing about it, but benchmarks show it slows things down (at least with shapefiles)
aaime Ah, I see. Nice.
jgarnett That feature reader wrapper may still be useful, shapefile is nice and memory mapped, other datastores may still benifit.
aaime By the way, that FeatureReader wrapper seems to be a solution in search of a problem. Anyone thinking about a place where it would be useful? Multiprocessor machines would probably benefit...
jgarnett Can put it in the grab bag, maybe some datastore developer will find it is the tool they need.
aaime If you think it can be nice, I can complete it by making it a FeatureSource wrapper so that it can be used to build a MapContext easily
jgarnett Just pay attention the the events so you know when to flush your buffer :-)
aaime Hum... ah, yes, which modules should I put it in... along with the FeatureSource wrapper it should be made of 3-4 classes
jgarnett org.geotools.data.buffer?
jgarnett similar to org.geotools.data.memory...
aaime ? The buffer is flushed when the FeatureReader is closed
jgarnett Ah I though you might keep it between runs.
aaime Not package, module. Am I going to commit it into main?
jgarnett If the data is small enough.
aaime I'll leave that feature as an exercise for the reader ;-)
jgarnett It seems that main is the place to play, we tried to have a talk about split out some of the test cases last week.
aaime Ok ok, maybe we should get back to the main topics :-)
jgarnett David did you manage to find enough test data.
polio i think so, paul found me a bunch (still need to use it)
polio was kinda giving a head up on org.geotools.xml
jgarnett There is a link on the wiki: http://docs.codehaus.org/display/GEOTOOLS/Extending+The+XML+Parser
jgarnett that contains a bit of an overview on the xml parser.
polio the xml package was going into main, and was hopping to create a gml datastore module
jgarnett That would be 4) but we could vote now :-)
jgarnett something like plugin/gml?
polio that was my though
cholmes I'm +1
polio t
jgarnett +1
aaime +1
jgarnett (hey does this mean you get to be a module maintainer :-) )
jmacgill +1
ian +1
jgarnett Were we still going to do the IanS/DavidZ as co - module maintainers?
jgarnett Congrats!
aaime Only IanS can tell...
aaime Which Ian do we have with us tonight?
polio don't think he's here ...
polio but was hoping to volunteer chris to help :)
cholmes gee thanks!
cholmes Yeah, I can definitely help out.
polio cool, thanks
aaime Ah, can I add a late topic? wkb4j
jgarnett Anything else david?
polio nope :)
polio next topic
jgarnett 3) GeoAPI update!
Martin We add a first telecon todayt
Martin (typo: we had...)
jgarnett Thanks for setting that up.
Martin This is actually Greg who set that up
Martin One topic was Feature.
Martin We need someone from Geotools to carry the comparaison of Geotools Feature interface with Degree Feature interface, and working with Degree to reach an agreement on a common interface for GeoAPI.
Martin Volunter?
jgarnett I have tried to help out, at least keep tabs on the process. But I don't have enought time to do a *good* job. And this certaintly needs to be done right.
jmacgill I would point out that GML is THE data source that pushes the feature model
Martin On my side, I will be totally unable to work on Feature. Any other volunter?
jgarnett Hmm this is important stuff and not something we should let slide.
polio I'm not sure I have the time atm to put into that, as I need to get a wfs datastore done fairly rapidly
jgarnett If we don't get a volunteer, the PMC should probably take the pain as a group.
aaime I'm going to miss for three weeks and don't know anything about GML...
jmacgill I think we should have as many of us as possible on the geoapi list
jmacgill and thrash it out on there
jmacgill Can the new gml parser handle nested features?
jmacgill is there a way to query the application schema for type inheratance info?
polio when there is an attribute factory for a feature
jmacgill would we need an attribute factory per featuretype?
polio nope, just for a feature
polio the featuretype would be known, and created
polio so just needs to take a known featuretype, and create an attributetype from that
Martin One other issue on the telecon was the target version: J2SE 1.3 or 1.4. Does anyone need 1.3 support, or is 1.4 okay?
cholmes I'm good with 1.4
aaime 1.4 is okay
Martin There is some chances that Degree still attached to 1.3. I asked for 1.4 on the mailing list today; we will see if there is opposition to that.
Martin One more issue was the version on CVS: I'm considering to ask for 1.5 source code on the CVS *only* (the release would still 1.3 or 1.4 source code). The reason is that we could une method annotation, which is a new 1.5 feature, for helping to build a tool mapping Java method to the UML they come from.
aaime So, what do we do? Start a wiki page where everybody can contribute and use the mailing list for feedback, coordination and discussion?
Martin It would be part of a validation process, in order to check if the Java interface comply to OGC UML.
Martin Start a wiki page where everybody can contribute to what?
aaime Martin, you could also use javadoc tags, like XDoclet does, isn't it?
aaime The Geotools2/Degree Feature model comparison
Martin Andrea, yes but annotation as more capability. I tried doclet (looks at the "scripts" module; there is already one looking at the @UML tag) and the capabilities are limited.
Martin Annotation is also checked at compile time, which would help to reduces the errors.
Martin The source provided in the release would still 1.3/1.4. Only the CVS would be 1.5, for development purpose.
aaime But it would also make it more complex for people to get started and participate in geotools. Is it something that can be done only in GeoAPI?
Martin Yes, I'm talking about GeoAPI only. I was not talking about Geotools at all.
Martin It was about some issue we talked about in the GeoAPI telecon.
aaime Ok
Martin An other issue was mutable geometries.
Martin Different approach: 1) no mutable geometries; 2) listeners 3) optional method likes the Collection framework or 4) don't bother.
jgarnett That is a tough one, I would love if the geometry interfaces were not mutable. And implementations can take the pain of providing their own mutation and events if they want.
jgarnett In anycase we can take this to the geoapi list.
Martin The guys who really want mutable geometries are Degree. Polexis (and Jody :) ) prefers immutable ones.
Martin Okay.
jgarnett I am not sure if geotools has a position on this one?
aaime brb
Martin On my side, I would not like events mechanism. I would prefer 3 (something like the Collection framework - there is no listener or events there)
cholmes I'm for immutable geometries - 3 sounds good to me.
Martin Right now, geometries are immutable in current GeoAPI version. So the conclusion is: do nothing for now, and maybe try to talk about that in the next OGC meeting (it would be easier than by email)?
jgarnett We did not talk much about Metadata, although the catalog MetadataEntry interface was not shot down.
jgarnett Are we done?
Martin As a side note Jody, do you allows me to refactor current org.geotools.metadata.iso19115 into org.geotools.metadata and remove the old org.geotools.metadata.iso19115 when I have finished the move?
jgarnett yes!
jgarnett please.
Martin Thank. I missed time for doing that today (I just commited an InternationalString implementation a few minutes ago), but will try to do that tomorrow.
jgarnett I had to add a SetOf, and ListOf class to preserve your idea of typed Sets and Lists.
jgarnett So I think you have all the bits you need.
Martin I'm considering moving them to org.geotools.util. Would it be okay for you?
Martin (I mean moving SetOf and ListOf)
jgarnett Sure. I may want to look at AbstractMetaData again to make sure it is okay.
jgarnett 5) 2.0.x cleanup/out
jgarnett I have just removed ext/view and am going to remove DataSource and GridCoverageExchange.
jgarnett Anything else that needs to be removed or cleaned up for RC1?
jmacgill I don't think so. I need to port my release script over to that branch
Martin Again we may delete the org.geotools.coverage package, since it still not ready.
jgarnett okay
jmacgill we will also need to replace the use of geoapi-SNAPSHOT with a dated version number for the 2.0 branch
jgarnett I would like to aim for RC1 at the end of the month
jgarnett - but really chris is in the driver seat as GeoServer 1.2.0 is based on 2.0.x, when do you need this for chris?
aaime back (finally)
cholmes I'm hoping the end of this week.
cholmes More realistically mid-next week.
aaime Well, we have a little problem with wkb4j
cholmes next friday is my absolute deadline, as I'm out of new york city after that.
cholmes What's the problem?
jmacgill chris, will my getFeatureInfo code be included?
aaime The problem is that we need to apply a couple of patches but I can't contact the author...
jmacgill what license is it under?
aaime LGPL
jmacgill so we can release a modified version with a link to the code (for now)
aaime There is no forum and I get no answers to my emails...
jmacgill I suggest a version number like wkb-1.0-modifed.jar
aaime Ok, I can build the jar. Where can I put the modified code?
jmacgill just include your email
jgarnett put it in geotools/spike?
cholmes Did you email wkb4j-users? Maybe someone there will know how to get in touch with him...
cholmes http://sourceforge.net/mail/?group_id=66278
aaime No, I did not... I supposed I needed to be subscribed... moreover, the mailing list is dead since 6 months
aaime Is anyone subscribed to that mailing list?
cholmes yeah, I am.
cholmes (I think)
aaime I'll forward you the e-mail then. You can send it cc'ing me
cholmes cool.
jmacgill I have a qn for aaime re lite render once we run out of agenda items
jgarnett 4) New module
rgould allo
jgarnett I think we missed you
jgarnett and went onto the next agenda item.
rgould I will be installing the WMS client source code into Geotools shortly, and will be needing my own module space for it
jgarnett It is a hard one to name
ian what sort of client?
jgarnett org.geotools.data. wms does not work since it is a client.
jmacgill wmsconnector
aaime Be right back
jgarnett I think it is a GCE
rgould One that we will eventually use for uDig.. I am doing it up as a GCE
cholmes Why is it in geotools and not in uDig?
ian so more of a wms datasource?
jmacgill yes
cholmes ah, ok that answers my question
cholmes perhaps data/wms ?
jmacgill as a package, yes
jgarnett that almost implies it is one.
jgarnett wmc - for web map client?
jgarnett wmsgce?
jmacgill wmsc
ian what are we going to call the wfs datasource?
rgould I agree with something like wmsc
-->| aaime (~wolf@host244-78.pool80180.interbusiness.it) has joined #geotools
aaime back
polio havn't figured that out yet, was hoping to follow richard on that
ian I'm not sure wmsc is clear
rgould wms_client?
ian its not really a client though
jgarnett data. wms is probably as good as it gets
jgarnett everything in data is a datastore
ian that works for me
jgarnett data.oracle is not a oracle, so people should be able to figure out what data. wms is.
rgould works for me
cholmes me too.
polio +1
jgarnett +1
jmacgill hangon, what are you proposing?
jgarnett plugin/wms with package org.geotools.data. wms
jmacgill for the module name? data. wms???
jmacgill oh, ok. yes.
jmacgill +1
ian +1
jgarnett I can help set him up with a module and be module maintainer with him for a bit.
jgarnett That is it for agenda items.
rgould thanks
jgarnett Andrea you had some lite renderer stuff?
aaime +1 me too
aaime Well... did anybody tried out LiteRenderer2?
jgarnett LiteRenderer2?
jmacgill no not yet. Though I suggest that on trunk you just make the switch
aaime Does anybody read the devel mailing list?
aaime (just kidding ;-) )
jmacgill i.e. the best way to get people to try things is to force them :)
jgarnett Ah yes, I remember now. Sorry andrea I did not get to try it out.
aaime James, yes, but I did not want to be that rude ;-)
cholmes Yeah, I'm going to try it out with geoserver soon - didn't have a chance to do anything last week except talk about spatial data infrastructures :)
jgarnett That is okay it is what we expect from an exhualted leader :-)
cholmes I'm hoping to get it into 1.2.0
aaime Ok, ok, I'll just renane it to LiteRenderer so that people start to get interest in it (or, if everything goes well, no-one may notice at all...)
cholmes cool.
jgarnett Part of the fun of having an unstable branch.
jgarnett Hmm chris does this mean you are going to port it across to 2.0.x?
cholmes Uh, yeah, that just occured to me - in that case I think I'll wait until 1.2.1 or something
jgarnett You have to wait on the GML parser too :-)
jgarnett Best way to encourage that 1.2.0 release :-)
aaime Jody, a quick question about udig: are the plugins you have commited to cvs only emtpy shells or they are already functional?
jgarnett Sigh
aaime Moreover, how are you going with the renderer questions?
jgarnett you caught me out, we managed to learn a whole bunch last week (placed in the developers guide) and will have to clean up the mess before things are useful again.
aaime Sorry Jody, but I'm definitely overloaded and now I'll be away for three week (holidays)
jgarnett Well Jesse is now in shock -
aaime So I did not tried it out... it seems it's better like this ;-)
jgarnett he is the render guy :-)
jeichar yikes. I have a skeleton right now and was starting rendering next week :(
aaime I'll be in Tunisy next week. But then I'll be back for a couple of weeks, and then again away for 10-15 days.
jeichar Well what happens happens. At the least I'll have some very good questions for you then. For now though we have a design
aaime Sorry, I just learned it's spelled Tunisia also in english...
jeichar we should be able to take that quite a ways. I'm hoping to plugin lite renderer first and hopefully its all go just great :)
jgarnett We should be okay, our design is informed by geotools. We have GeoServer for a working example of using LiteRenderer(2). But you will be missed
aaime Don't commit too much on Lite... I'm still hoping to learn the j2d internal in order to make it a "memory limited" renderer
aaime Anyway, next Monday I won't be here, so don't look for me ;-)
Martin It is really becoming urgent that I free myself from my @#!* thesis so I can work on renderer (after CRS, metadata, coverage...)
aaime After too many things then... I guess Jody and Jessie need something working within no more than two months... maybe just one...
jeichar I was going to use lite first because theory has it is simpler then when some of the issues have worked out try out j2d for a more complete solution...
jeichar yeah about 1-1/2 month we need rendering.
jgarnett http://docs.codehaus.org/display/UDIG/Schedule
aaime I see. For basic rendering it changing them should be a snap, supporting selection and the like would be harder to port...
jgarnett qualified yes ... I think we were going to use Filter to handle selection.
jmacgill is happy to here that
aaime Oh oh... lite will be painfully slow for that unless you map geometries in a memory data store...
jeichar we will have many rounds of optimization...
Martin Proshun has an implementation for selection on top of J2D renderer. But I miss time for reviewing and commiting his code.
jgarnett On the other hand running out of memory is slow to.
jeichar really! that would be interesting to look at.
Martin It is really not new.
Martin (looking at the URL...)
jeichar no? what do you mean.
Martin http://jira.codehaus.org/browse/GEOT-80
Martin He posted the code 6 months ago.
Martin I started to integrate some of this code in the trunk, but miss time to finish the integration.
Martin (Proshun's code is the attached files in GEOT-80)
jeichar So it would be under geotool's license?
Martin (actually, he sent me some updated code since this time)
Martin Yes.
Martin I can sent to someone the rest of the code, if someone want to finish the integration.
jeichar cool. I can't promise anything because we have a fairly strict plan... but I'm sure it'll come in useful.
jeichar I think september is the selection feature editing period for udig
jeichar selection and feature editing
Martin J2D renderer was designed with at least some simple interaction in mind. But the API ignore filter. It would need refactoring, but some fundation are there.
jeichar I'm sure no matter what solution we pursue there will be refactoring.
aaime Martin, the real problem is that j2d completely ignores geotools... my factories are just a band-aid...
Martin I know
Martin I want to refactor it. If someone could finish my f...ink thesis for me, I would be more than happy to do this work.
aaime One of the things I feel we need doing, is to reverse the relation: the renderer layers pull things out of the feature source and styles as needed, now it's the opposite...
jgarnett The GeoAPI Geometry/Canvas split actually provides a series of interfaces for formalize the difference between Feature and the rendering process.
aaime This is badly needed in order to build a layer that can limit itself to cache data instead of having everything in memory...
aaime And the latter feature is needed for serious GIS... otherwise you're just playing with toy amounts of data
jeichar jody that's graphic/canvas interfaces
jgarnett sigh you are right - two many specifications battling for headspace.
jgarnett It is a interesting idea - reversing the FeatureSource / Layer relationship.
jgarnett Don't you still run into the problem of when someones trys to view "everything"
aaime No if the layer holds rendered geometries and resolved styles in a spatial sensitive cache instead of insisting on keeping everything in memory. Lazy loading as requested and the like...
aaime But we need that kind of cache, caching at the granularity of single geometries can fire back with too much overhead.
aaime (memory overhead I mean)
aaime We need to cache with a granularity of a set of rectangles and drop out the geometries that fall in the rectangles that are not on the screen.
aaime If too much data is needed, just stop using the cache and fall back on pure streaming.
aaime Otherwise we end up spending time mantaing a useless cache (this happens if the data to be displayed is twice the size of the cache or more and the cache acts as an LRU container).
aaime Ok, I probably got everybody sleeping...
jgarnett Nope I am thinking too much.
jeichar No but a full head I admit.
jeichar heh
Martin I will have to go soon (is 23h30 on my side and I have one hour walk for going back to home). Is there other issue for today?
jgarnett The whole cache thing is fun
jgarnett I have been talking to david blasby about indexing our pickle format.
aaime Well, it's just a compromise: lite does full streaming, j2d keeps everything into memory, we need a compromise, that is, a cache, in order to reuse rendered geometries. But the cache needs to be spatial data aware and must get out of the way if it starts to just slow down things.
jgarnett (or shapefile for that matter).
jeichar how does our data store handle the sort of access we'd need for lazy loading?
aaime And finally, lazy loading is of paramount importance, or we won't be able to connect to huge layers...
aaime Lazy loading at the level of renderer geometries creation: ask the data store only the data we need at the moment. The data store does not need to be changed. It just need to be fast at bbox queries.
Martin It bring us back to the idea of a common set of interfaces for different renderer implementation (so an application can switch to a lite-renderer in a transparent way if there is too much data). The GO-1 interfaces may be a starting point. If some point need to be fixed, lets try to talk about that.
jgarnett we have actually set up a common set of interfaces at the uDig project level.
ian caching at the datastore level is easier
aaime That would be a really simple solution... if you get an OOM, the current layer switches to streaming...
jgarnett And plan to switch between them. WMS for remote rendering, vs the WFS with local rendering as metrics change.
Martin Is there any relationship between the uDig interfaces and the GO-1 ones?
jeichar uDig interfaces are closer to J2d renderer. than GO-1
aaime Ian, building rendered geometries is expensive, decimating them too, so it would be better to cache at that level... Features are just too raw and too fat rendering wise...
Martin Furthermore, caching a decimated geometry use less memory than the full geometry :)
jgarnett Part of the fun is coming up with a model of the performance of the different rendering options for a Layer, and switch between rendering pipelines as needs change.
aaime Data store level caching is useful for Lite, but not much for j2d....
aaime Martin, caching only the decimated geometry is useless, at the first zoom in you have to reload the actual one...
jgarnett can I ask a newbie question?
jgarnett what is a decimated geometry?
Martin Generalization.
aaime Geometries usually have many more points than you need for rendering
aaime So we do apply, both in lite and j2d, algorithms to reduce the number of points we send to the graphics card.
Martin In J2D renderer, the algorithm is quite simply. Just discart any point at a shorter distance than some threshold.
aaime j2d does more, it remembers the decimated form, if you zoom out you can simply decimate it more, if you zoom in slightly, the decimation can be reused
aaime This is one of the reasons j2d is so fast at zooming...
Martin J2D also do one more step: it clip the geometries to the viewing area too.
aaime (at least when you zoom with the scroller on your mouse)
Martin So it cache the clipped and decimated geometry.
aaime Martin, clipping is useful with big isolines, maybe just overhead when dealing with less oblungated geometries...
aaime Do you have benchmarks on that?
Martin I use big geometries on my side.
aaime Ok, I meant, can it be disabled?
Martin Yes (searching...)
Martin In RenderedGeometries, set CLIP_CACHE_SIZE to 0 (default value is 8)
Martin In my experience, it may a big difference for big geometries. Not sure for small geometries however.
Martin (type: it may ==> it make)
aaime This will disable clipping altogheter?
Martin Yes, this disable clipping in J2D renderer.
aaime (I want to avoid the computation, not only the memory overhead)
ian ok I'm off to bed - I'll ponder this some more
aaime I see.
Martin It should disable computation as well.
jgarnett Well the more I listen to this discussion the more questions I think I am going to have.
jeichar Martin, you'll be around for some of the next month so I can ask you for advice?
Martin Yes, I will not have any vacation for a while.
aaime Jody, yes, it's not an easy topic...
jgarnett .. but very interesting.
aaime For sure... that's why I try to stay in that area of the geotools source code base ;-)
jgarnett I actually implemented a renderer for a previous company. I used a raster cache, and Shape+Pain.
Martin (typo: vacation --> holiday I think... Do many language deformations)
Martin (typo: Do ==> Too)
jgarnett pain = paint
jgarnett although pain may be descriptive.
aaime :-)
jeichar and aaime, will you have an hour or two when you get back if I have some questions? (Which I will)
aaime Of course. There are two thing I want to do in the next couple of monts:
aaime - work on the renderers (at least reverse engineer and completely understand Martin's work)
aaime - learn to build applications based on Eclipse RCP
aaime So I guess I will be working of topics quite near to udig ;-)
jeichar :)
jgarnett Fun. We will try and blaze a trail for you.
aaime It's getting too late here... going to bed. Bye everybody :-)
jgarnett Okay I am going to collect the logs
Martin I have to go too. Bye all
jeichar Yeah I have to go too. bye all
jmacgill cheers all

This page is powered by Blogger. Isn't yours?