Summary:1. Renderer interface 2. ViewportModel 3. Date 4. Catalog API
jmacgill Hi all
dblasby hay, I have a question about attributetype and the actual object
dblasby in the FEatureTransformer, it just calls value.toString() to get its value. Shouldnt it be calling type.toString(value) or something. This is more like the way the geometry attribute is handled.
dblasby I'm just tracking down Date/Time problems. PostGIS is returning the value in a java.sql.Date and the Date.toString() method doesnt do the job "correctly"
dblasby or type.toXMLString()
dblasby or some such thing.
cholmes probably... But we don't. Maybe in the next featureType stuff.
cholmes Did you get my fix?
cholmes It's a hack, all it does is make the value.toString return the right xml thing...
dblasby yes - but, unforunately, it doesnt actually do anything since that code isnt really called
cholmes since no one else actually cares about the format of the string.
dblasby well, its not correct XML in its current form.
cholmes Really? I swear there are users who tested it and got it working.
cholmes well, the last version I did at least.
dblasby and there's the whole problem of having java.sql.Date store timestamp, ts with tz, time, and time with tz
cholmes it should turn the object into a DateTime object, whose toString() method does the xml way.
dblasby well, the transformer code just calls value.toString() and value is a java.sql.Date so it doesnt use the TemporalAttributeType code at all.
cholmes Yes, I admit that's a problem, and it needs a better solution.
cholmes Oh, that's easy to fix, I think. Just have the 'parse' method also transform a sql.Date into a DateTime object.
dblasby okay
dblasby I see
cholmes Though I'm sure why the code isn't having some sort of error, and just accepting the sql.Date...
cholmes I'm not sure
dblasby if (type.isAssignableFrom(value.getClass())) {
cholmes yeah, that's what I was just wondering about...
dblasby type is a java.util.Date
dblasby it should probably be a DateTime
cholmes DateTime extends Date
cholmes so I think it should be fine.
dblasby but then it calls Date.toString() instead of DateTime.toString()
dblasby if (value instanceof java.util.Date) {
dblasby thats what its supposed to catch
dblasby I think it will work if we set the type to "DateTime" instead of java.util.DAte
dblasby ..
dblasby meeting starting?
dblasby ...
cholmes Ah, yeah
jmacgill indeed
cholmes stupid error from me typing this code in for the second time...
cholmes You can also try the class file from: http://jira.codehaus.org/browse/GEOS-311
cholmes I thought the .java was under svn, but it didn't make it.
dblasby okay , so change the class to DateTime (from Date)
dblasby ?
cholmes wait, sorry, where are you looking?
cholmes to do that change?
dblasby in TemporalAttributeType
dblasby looks like its working.
dblasby <tiger:ts_without>2005-09-09T19:18:55.635</tiger:ts_without>
dblasby all the Date-like types get represented the same, though...
dblasby ...
dblasby Topics for meeting?
dblasby ...
dblasby 1. Renderer interface in 2.1.x and trunk now
jmacgill 2. Design of a ViewportModel class
dblasby 3. Date stuff (Timestamp/Timestamp with timezone/Date/Time/time with timezone)
dblasby ..
dblasby any others or should we start?
jdeolive 4. Status of udig Catalog API backport
dblasby ...
jmacgill ok, that should keep us going
dblasby okay, #1
dblasby As I said in email, i put the interface, utility class, and implementation in 2.1.x and trunk
dblasby The next step will be to remove literenderer and literenderer2 from trunk
dblasby but i didnt want to do that...
jmacgill but the interface is in the lite module, which I do not like
dblasby jessie said he was going to move the test cases over
jmacgill and the next step would be to deperceate them on trunk!
jmacgill not remove, much as we would like to
dblasby I think they're already depricated
dblasby oh wait, lite2 is depricated
dblasby okay - so now the time to put your 2c in on this...
jmacgill if lite2 was depriceated at the time of 2.1 then it can die
jmacgill we would nee to look at the javadocs for 2.1 at teh time of release
dblasby I think it got depricated and moved to literenderer (no "2")
jmacgill I'll download the 2.1 src archive and check
jgarnett (or just check javadocs for 2.1)
dblasby either way, I just wanted to warn folks.
dblasby EVERYONE SHOULD USE THE NEW StreamingRenderer – its pretty much 100% back compatible...
dblasby (actually use Renderer type, StreamingRenderer implementation)
dblasby anyways, this leads on to 2. Design of a ViewportModel class
jmacgill can you replace the Renderer interface at the next package up rahter than putting the interface into lite?
dblasby I thought we had to depricate first then remove a version later...
jmacgill there is a get out clause in the Renderer interface
dblasby (I'm happy to overwrite it, but then literenderer will need changes since it current implements the current Renderer interface
dblasby just need an okay to do it.
jmacgill how hard to make the existing literenderer implement the new interface?
dblasby ..just replace it with StreamingRenderer
dblasby which is just lite2 with changes to make it implement the interface
Jesse_Eichar LiteRenderer should be compatible with the new interface.
jmacgill so we should be able to replace the existing Render interface, and still have Lite implement it
dblasby the Hints (both of them) are different
dblasby thats where all the work was
jmacgill can you bolt the hint handling code into Lite (I know we should not be touching it)
dblasby thats EXACTLY what streamingRenderer is – just lite2 that implements the new Renderer interface.
jmacgill I'm trying to find a way to replace the Renderer interface wihout takeing the implements clause off of the LiteRenderer class
dblasby ... hummm... so of the set/get functions maynot be there since they've been replaced with the get/set Hints system.
dblasby "so" = some
dblasby is anyone using Renderer?
Jesse_Eichar No I
dblasby we could just replace it and remove the lite2's implements clause
jmacgill ok, lets do that instead - I have to update some code in Studio but not much
dblasby ... you should just use the new renderer instead of relying on the old one?
jmacgill will do
dblasby jmacgill 2. Design of a ViewportModel class
dblasby is the geowidget fellow here?
jmacgill I don't think so, no.
jmacgill But given that Jesse has something similar in uDIG...
Jesse_Eichar That's right. Do you want a summary of what it is?
jmacgill please
Jesse_Eichar Pretty simple.
Jesse_Eichar In udig we have the map, which has layers and a viewport model which has a Area of Interest and a CRS.
jmacgill SO you don;t use the context object at all?
Jesse_Eichar I don't know what we will have in geotools but in udig the Viewport model knows about the display so that the area of interest will have the same aspect ratio as the viewed area.
Jesse_Eichar no we don't.
Jesse_Eichar That's about all it was. Most a seperation. The map knows the bounds of the map and the ViewportModel knows about the screensize and the area of interest.
jgarnett (and time)
jmacgill does the crs in teh viewport = the crs in the layers? or does it drive reprojection
Jesse_Eichar the crs in the viewport usually does not equal crs of a layer.
Jesse_Eichar It drives reprojection.
jmacgill does it also provide the toScreen and toWorld utility methods, or are they in a seperate utility class?
Jesse_Eichar I was talking to a client and he really wants to be able to set a zoom level. That is something we don't have and should think about.
Jesse_Eichar It provides those method.
Jesse_Eichar setZoom(100) where 100 is an absolute value derived from the size of the world I guess.
jgarnett Wonder if it can be made to reflect the "scale" concept from SLD?
jmacgill Is the AOI an object that could be shared amoungst viewports? (and or overview map components)
Jesse_Eichar What is that?
Jesse_Eichar AOI is an Envelope currently.
Jesse_Eichar (What is that to Jody)
dblasby scale is just the Representative fraction denominator
jgarnett SLD scale is a pure number, documented by them. You can use the same documentation & calculation if you want.
dblasby ie. 1/50,000 --> scale = 50,000
jmacgill it makes some hard assumptions about dpi
dblasby <MaxScaleDenominator> <MinScaleDenominator>
Jesse_Eichar ok thanks. That works.
jgarnett still viewport model does not have to make the dpi assumption - it should know.
jmacgill do, it dosn't
jmacgill are you showing it on a 14inc screen or a 8 foot projector?
jmacgill same no of pixels, different number of pixels per inch
dblasby ya - you have to know the device to convert your pixels to something real
jgarnett And I think we already did (so we could get the aspect ratio right)
dblasby ogc say to use 96dpi if you dont know. But, thats still not great...
jgarnett Aside: I have the oracle hackfest moving along, just got the table creation back in the game.
dblasby aspect ratio can be represented with pixels (assuming they're square)
dblasby but you need a way to link your pixels to the real world (ie DPI)
dblasby in order to get a scale RF
jmacgill ok, I think thats as far as we can go on that topic for now. Just watned to start gathring info
Jesse_Eichar That's all I can say for now.
dblasby 3. Date stuff (Timestamp/Timestamp with timezone/Date/Time/time with timezone)
dblasby Chris and I just changed TemporalAttributeType to produce DateTime objects.
dblasby but, the main outstanding problem is that all data/time entities (ie. Timestamp/Timestamp with timezone/Date/Time/time with timezone)
dblasby are being represented with the same object.
dblasby to fix it probably means changing how the datastores code the objects
dblasby for example, the jdbc driver maps all the date-like types to one Type
dblasby which means that you get some screwy results
dblasby sorry - the internet dropped for a bit therer
dblasby what was the last thing I typed?
jgarnett Dave looking at this code now - for oracle.
jgarnett There is a lot more that should be done. Nothing is hooked up right now - not even max field length or nillable.
dblasby yes - but now we're having Date (ie. 1/1/2005) and 11:45 and june 4 9:00 all being represented exactly the same.
dblasby <tiger:date_col>2005-09-09T04:00:00</tiger:date_col>
jgarnett Yes, but as long as we track the mapping so we can reverse the process we should be good?
dblasby you get a result like that for ALL types
dblasby hopefully
dblasby but I'm not exactly sure what to do for insert/update
dblasby might just need a bunch of logic.
jgarnett Consult the database metadata, I think it is already done for you.
dblasby asSQL( type_code )
dblasby okay
dblasby but you will not know info because its currently just mapping to "Date"
dblasby but it might be okay when you do an insert
dblasby I might fix this type of thing next week for postgis.
jgarnett Cool. In geoserver you already track the schema mapping so you can use that to figure out your required gml genreation ...
jgarnett It just may not be "automatic", as the info will get lost by AttributeType on route from database metadata to geoserver FeatureTypeInfo
dblasby Ya - we might need a bunch of different temporalattributetype classes
dblasby I've never poked around in this stuff, so I dont really know whats supposed to happen....
dblasby so - anyone have any problems if i do that on 2.1.x?
dblasby or should I put it on 2.2?
dblasby since its a little experimental
jmacgill I would prefere expermental stuff to happen on 2.2
dblasby okay- I'll make a jira note & hopefully get back to it.
jgarnett dblasby - no need to hack. Do your restriction with Filter and no api will change.
jgarnett (aka this is why we did "facets" for 2.1)
dblasby okay - I dont know how its going to hook in since its not really a restriction.
jgarnett It is in the XML sense, you have the universe of all Date objects and you want to restrict it to just the Time component: (Any Day specific time) or Date component: (Specific Date any time)
jgarnett But lets go on ...
jmacgill I have to head home
jmacgill \who
dblasby perhaps, but there's timestamp and timestamp w/ tz
dblasby last item was from jdeolive
jdeolive I have been looking into backporting the udig catalog to geotols
jdeolive i know that there has been some work going on
jdeolive just wanted a status from the people involved
dblasby whos doing it?
jdeolive I think jgarnett can comment
jgarnett Not sure where to begin, do you guys really need the history again?
jdeolive werent some people on the geoserver list talking about doing the work
jdeolive i know the udig catalog quite well, so I guess I am volunteering if no one else is
jgarnett Sort of, they were unaware of the work. MatthiasB was starting in on the work for GeoWidgets.
jgarnett I don't see any of the people here ...
jdeolive ok, i will fire off Matthias an email, i have a couple questions for him anyways
CIA-10 dblasby 2.1.x * r15677 geotools/module/main/src/org/geotools/feature/type/TemporalAttributeType.java: changed ref class to DateTime from Date.
jgarnett thanks jdeolive, sorry I was not on the ball - perhaps cholmes can describe the different geoserver work that is starting to play in the catalog/registry space?
jgarnett sorry catalog/repository space ...
dblasby I dont think chris is still here
jgarnett Have you been keeping track dave?
dblasby there are people working on the "Ingestion" engine at the moment – thats the only active changes I knowof. They're just going to use the current stuff, though...
jgarnett That is not what I got from talking to them ...
jgarnett they were happy to find the "Repository" interface.
dblasby I dont thnk they're actually using it though
dblasby you mean the udig catalog, right?
jgarnett http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastructure
jgarnett That was the RnD link
dblasby I thought they were doing their own thing. Unless you know more than I do...
jgarnett I have been reading the email lists, and swapping email. I think all the messages were CCed to the list.
dblasby ok
jgarnett I found the going fairly tough, in terms of Paolo being surprised at being asked questions, and in terms of him not having found the existing infrastructure - and knowning that we are all willing to adapt it.
jgarnett A big thing for him was "cross datastore" opperations, and having a "repository" that let people work against feature sources with out regards to where they came from.
jgarnett But no more details ...
dblasby I'm not sure what their plan is. I think they've already got a working (well maynot not working) implementation. They've done A LOT with datastore, so I think they are doing things inside a Datastore.
dblasby WE;ll have to ask them.
dblasby Anyone have any other comments or topics or should we close things for today?

<-- jdeolive has left freenode ("Chatzilla 0.9.68.5 [Fedora 1.0.6-1.2.fc3/20050909]") jgarnett I think that may be your answer dblasby a resounding silence. dblasby okay - have a good evening everyone. jgarnett Can someone gather the logs? dblasby? dblasby my client truncats the log. dblasby I tried posting the dox stuff earlier and lost the 1st bit.