Thursday, March 26, 2009

UDIG 1.2-M3 Released

Normally I would tell you what great new thing is in a release - this time I would like to ask you to look at the release notes!  An amazing 60 bugs closed (and 13 more waiting for testers to verify).

This is the result of the "10 minuet code sprint" where the development community got together and fixed as many bugs as they could over the course of a couple of days.

The UDIG 1.2-M3 release is available here:
- http://udig.refractions.net/download/unstable/

Tuesday, March 24, 2009

AXIOS UDIG EXTENSIONS 1.1.2

This release, available for uDig 1.1.1, includes new improvements and bug fixes. We want to highlight the following main improvement:

Split Operation. We have improved the split behavior by allowing the tool to add one or more vertexes to the neighbor geometries (whose boundaries are intersected by the split line) of the one that has been split.

To test this new release please visit the uDig update-site or our web site www.axios.es download page. Here you can find the latest stable release Axios uDig Extensions 1.1.2, as well as the latest under development release Axios uDig Extensions 1.2-M3 for uDig 1.1.1.

If you want to know more about this project visit the following page: Spatial Operations and Editing Tools

We want to thank Rudolf Hochmeister from the Municipal Department of Automated Data Processing, Information and Communications Technologies, Vienna City, for his contribution to improve this project.

Friday, March 20, 2009

udigLite: An OSGi-friendly subset of uDig

Depending on your environment, you may find it hard to integrate other OSGi bundles or Eclipse plug-ins with uDig. My team and I have tried for some time to build a viewer application for a proprietary car navigation database format on top of uDig 1.1 releases or uDig 1.2 trunk snapshots, fighting with version conflicts and class loader issues caused by the "grab all you need" plug-in net.refractions.udig.libs.

The root of these problems is Geotools and its dependency on the META-INF/services mechanism, which requires some trickery to be made compatible with OSGi.

We have now succeeded in creating a minimal subset of uDig and Geotools which solves these conflicts by turning all Geotools and third-party libraries into separate bundles. For technical reasons, we had to work with cloned repositories, which should simply be regarded as a uDig working branch.

More details about udigLite can be found in the uDig wiki. Have a look at my blog to get an idea of what we are using uDig for.

Finally, thanks for all the support from the uDig community so far - we very much hope to join forces to bring the results of this activity back into uDig trunk.

Tuesday, March 10, 2009

TileSync


TileSync, based on uDig, developed by LISAsoft in conjunction with Landgate and ExaMin, allows a user to select any feature (Polygon) and add it as a Region Of Interest to a Region Of Interest View. The View allows the User to locally cache a any WMS-C Layer in the Catalog within the bounds of the Region Of Interest. The plugin also allows the local cache to be exported with TAB (MapInfo) header files and a seamless XML file.



Also included is a MapGraphic which outlines the Region of Interest on the Map View when it is selected in the Region of Interest View.


A bundled version is available for download here, and a copy of the plugin can be checked out of the uDig community SVN here.

I have made up some flash videos on usage available online:

Friday, March 6, 2009

The 10 minutes bug code sprint

What is the 10 minutes code sprint?



A code sprint in which bugs and feature requests will be fixed that are supposed to take only 10 minutes to the involved developer (in a perfect world).


Further info at the Osgeo wiki.

Thursday, March 5, 2009

IRC Logs March 6th

[07:06am] jgarnett: morning
[07:07am] jgarnett: emily_g ping? were you able to sort out where layer.refresh() goes?
[07:07am] emily_g: hello jody
[07:07am] emily_g: no
[07:07am] emily_g: I wasn't
[07:07am] emily_g: layer.refresh() doesn't fire any events
[07:09am] jgarnett: um it does something though right?
[07:10am] jgarnett: somehow it adds a bounding box to an area that needs to be repained for a layer
[07:10am] jgarnett: and queues up a RenderJob to handle it right?
[07:11am] emily_g: yes that sounds about right
[07:11am] emily_g: but there are no events there that I can listen for
[07:12am] jgarnett: um from the ui I can listen to the layer state changes; rendering, etc... I think I can listen for layer refresh as well
[07:12am] jgarnett: (I am sorry I am at home on funny mac thing and do not have the source code in front of me)
[07:13am] emily_g: funny mac thing eh? sounds like fun
[07:13am] jgarnett: so if there were no events RenderJob would of been called directly via layer.refresh?
[07:13am] emily_g: LayerImpl.refresh calls getRenderManager.refresh()
[07:14am] emily_g: now that I think somehow calls RenderJob
[07:14am] emily_g: but I guess I need to walk further into the code
[07:14am] emily_g: I kind of stopped there thinking I hit the wall
[07:14am] emily_g: but you have a point; I may need to go further and look at layer state events or render events
[07:15am] emily_g: I have a couple questions about the current udig graph module
[07:15am] jgarnett: sure
[07:15am] emily_g: 1 - it has very few to no comments; this really isn't cool if you are trying to understand what's going on
[07:16am] emily_g: 2 - it looks to me like you can only route on one dataset at a time
[07:16am] jgarnett: (although the news here is that if you need to change how graph works you can - it is not used much yet and has not seen public release)
[07:16am] emily_g: (the waypoints are stored on the map blackboard)
[07:16am] jgarnett: thinking ....
[07:16am] jgarnett: 1. you are correct about the comments; mostly that is because the graph functionality is document well on the geotools wiki
[07:17am] jgarnett: I should go through and add at least class level commens (ie meet the udig requirements for comments)
[07:17am] emily_g: ya; I think that would help
[07:17am] jgarnett: 2. this is something that can be changed I guess
[07:17am] emily_g: I'm not sure we need to change it
[07:17am] jgarnett: it depends on where you store the graph data structure
[07:17am] emily_g: I'm just trying to understand what is happening now
[07:17am] jgarnett: is routing actually making sense on more than one data set?
[07:17am] jgarnett: I could see a public transit one and a car one
[07:18am] emily_g: or trasit; car; walk & bike
[07:18am] emily_g: or maybe you want to test different dataset
[07:18am] jgarnett: but not both at the same time; you would set up what you need and then ask it to generate a route
[07:18am] emily_g: and see how the attributes give you different routes
[07:18am] jgarnett: yeah okay fair enough
[07:18am] emily_g: i'm sorry i'm making up use cases ... I don't actually have that use case ... yet
[07:19am] jgarnett: so the workflow for that package right now places a graph on the map blackboard; we would need it to change and place a graph on a layer blackboard; and make a single renderer to show way points and the route calcualted against that graph.
[07:19am] jgarnett: you guys are using pgRouting; and I am mostly interested in assuring you make use of the catalog api correctly
[07:20am] emily_g: I'm sure we are not
[07:20am] jgarnett: (ie it would be bad form to start doing data access connection stuff at the layer level)
[07:20am] jgarnett: did you get my origional message to Tim?
[07:20am] emily_g: yes I did
[07:20am] emily_g: but I'm still working on understanding it
[07:20am] jgarnett: I tried to think it through ... but I may of missed something. I assume he had gone through Service / Renderer / Style tutorials.
[07:20am] emily_g: You said somewhere that we should just use the postgis connection in the catalog - I don't think we can guarentee this is already a connection in the catalog
[07:21am] emily_g: our client also has some "weird" requirements that they want the connection stuff as a different bundle; so what we do for them will probably be a bit different from what we do for udig
[07:22am] jgarnett: um the requirements are fine
[07:22am] jgarnett: you can add functionality to the udig postgis from a different bundle
[07:22am] jgarnett: backing up to the larger picture
[07:22am] jgarnett: we want to make sure the postgis connection pool is managed stupidly well
[07:23am] jgarnett: and it would be good to share the connection between the postgis datastore and the pgRouting api
[07:23am] jgarnett: is that okay / understandable?
[07:23am] emily_g: yes - you want one connection
[07:23am] emily_g: makes sense to me
[07:24am] jgarnett: well one connection pool
[07:24am] jgarnett: so for your customer do you have access to the udig catalog?
[07:24am] emily_g: aren't connection pools managed by geotools datastores?
[07:25am] jgarnett: (this conversation kind of has two parts; one about how to manage the connection pool and another about how to intergrate with the graph tools)
[07:25am] jgarnett: not really; when you construct a geotools datastore you can hand in a connection pool
[07:25am] jgarnett: (or you can specifiy a bunch of optional parameters and ask it to create you one)
[07:26am] jgarnett: either way will work here; we need to get access to the connection pool for the PostGISserviceImpl
[07:26am] jgarnett: (I think there may already be a resolve target - for ConnectionPool or Connection)
[07:26am] jgarnett: I am not too worried about that ...
[07:26am] jgarnett: mostly about defining an API to access pgRouting; and then making sure you can get the connection pool in behind that api
[07:26am] emily_g: the thing is in the end our client may not want a direct connection to postgis anyways
[07:27am] emily_g: they may want it go to through some middleware connection
[07:27am] jgarnett: Do you have an API for pgRouting yet?
[07:27am] jgarnett: ah right - fair enough.
[07:27am] jgarnett: even more important to make an API then
[07:27am] jgarnett: (and consider spring remoting when implementing the api for your client - in order to reduce the cost of setting up the middleware)
[07:27am] emily_g: yes and no; I'm not really ready to answer that question
[07:27am] jgarnett: okay np
[07:27am] emily_g: i'm still working on it
[07:28am] jgarnett: at somepoint here will be some methods right?
[07:28am] jgarnett: hand in a start and end point and get back a route; or whatever other services pgrouting offers (I have only read about it)
[07:29am] emily_g: yes it is basically that
[07:29am] emily_g: pass in some points & route type and get back geometry
[07:29am] jgarnett: thinking
[07:30am] jgarnett: sorry for the distraction on the postgis front; going through some middleware thing is a bit different
[07:30am] jgarnett: I would probably handle it by defining that API
[07:30am] jgarnett: and sticking that object on the map or layer blackboard
[07:30am] jgarnett: and defining the graph tools against that object (or graph wizard or whatever)
[07:31am] jgarnett: and then I would implement using geotools graph
[07:31am] jgarnett: and implement using the middleware
[07:31am] jgarnett: and if we have call to talk to postgis directly I would go off and play that game.
[07:31am] emily_g: that's sort of what we are doing I think
[07:31am] jgarnett: in some sense that makes defining the api easier; since it comes down to what you need the tools to be able to call.
[07:31am] emily_g: without the geotools graph stuff because that is already handled for us by pg routing
[07:32am] emily_g: the problem I was having was want to do with our pgRouting API implementation; but you are correct - we can put it on the map blackboard
[07:32am] jgarnett: in anycase feel free to manipulate the graph module into that shape; it may even be a helpful move for your project since it would allow you to test prior to the create of the middleware bit
[07:33am] jgarnett: ah right - putting custom components on the map (or layer blackboard) is the way to go.
[07:33am] jgarnett: you may find that you need a bit more lifecucle control;
[07:33am] jgarnett: ie if the layer was deleted you may want to be told about it?
[07:33am] jgarnett: if that is the case we may need to look at making the blackboard a little smarter (ie more into a container)
[07:34am] jgarnett: but no sense causing trouble unless you have the need I figure.
[07:34am] jgarnett: um you did this approach for the birds demo; so I thought it would be fresh in your mind
[07:34am] jgarnett: (still want to write that demo up for others)
[07:34am] emily_g: ya; and I've used it for the mapgraphic rendering problem;
[07:34am] emily_g: just didn't clue into it; too many other things going on
[07:35am] emily_g: i have a meeting shortly and I need to eat so I'm going to run away
[07:35am] emily_g: thanks for the help
[07:35am] emily_g: is there an official irc meeting tommorrow?
[07:35am] jgarnett: okay; I will post these logs; and spend the rest of the meeting timeslot here on sorting jira bugs.
[07:35am] jgarnett: Today is friday for me; and this is the meeting timeslot.
[07:36am] emily_g: okay I'm confused between what day it is
[07:36am] jgarnett: Andrea wanted to go over Jira bugs (in prep for a code sprint) tomorrow
[07:36am] jgarnett: np
[07:36am] jgarnett: that is what weekends are for; to help you organize what day is where (or when?)
[07:36am] jgarnett:
[07:42am] jgarnett: thanks for the chat emily

Sunday, March 1, 2009

FOSS4G 2009: One week extension to Workshops and Tutorial submissions

Sydney, Australia. 2 March 2009.

In response to requests from presenters, the deadline for the FOSS4G 2009 workshop and tutorial abstract submissions has been extended by one week, to Monday 9 March 2009. If you are considering submitting a workshop, please notify your intent by emailing the Workshop/Tutorial coordinator, Mark Leslie m a r k . l e s l i e AT l i s a s o f t . c o m


About FOSS4G

FOSS4G, held 20-23 October 2009 in Sydney, Australia, is the international "gathering of tribes" for open source geospatial communities. The theme for the FOSS4G 2009 conference will be "User Driven". Users and developers are encouraged present their latest projects and software to demonstrate the power of Open Source for system integration through a series of workshop sessions and tutorial presentations. Session participants should expect to see presentations on both geospatial open source and propriety software integration along with pure open source solutions.


Workshops

Workshops are expected to be a hands-on experience with participants following along with the instructor, working directly with the application under discussion. All workshop rooms will be equipped with computers (two students sharing one system) to support this vision. Workshop computers will pre-installed with a basic image containing standard packages running in a Windows XP environment. A projector will be provided for each computer room for use within a workshop. Instructors will need to discuss pre-installation requirements with the Conference Organising Committee if required.

Workshops are expected to require considerable effort to create, with past experience showing that three days of preparation per hour of presentation are required to produce a high quality workshop. Additionally you will be expected to develop material for attendees to take home with them, such as handouts, workbook, CD-ROMs etc. Due to the effort involved in producing and presenting a workshop, instructors will receive a single complementary registration to the conference for delivering a workshop.

All workshop submissions will be considered, but particular interest will be shown in the following topics:

  • Practical Introduction to ____
  • Integrating Open Source
  • Spatial Data Privacy and Security
Tutorials

Tutorial rooms will not be equipped with computers, however presenters may optionally make use of delegate laptops and the FOSS4G LiveDVD.

At least 80% of delegates are expected to be carrying a laptop and FOSS4G LiveDVDs will be given to all delegates.

Preference will be given to hands-on tutorials.

Any hands-on aspects to a tutorial will be the responsibility of the presenter and needs to be described in the tutorial description. Presenters making use of the Live DVD or Climate Change Integration Plugfest (CCIP) will be expected to contribute to testing pre-releases to ensure material and software is properly installed. To discuss your requirements for LiveDVD, please contact the organising committee: http://2009.foss4g.org/contacts/.

All tutorial submissions will be considered, but particular interest will be shown in the following topics:
  • Practical introductions
  • Interoperability
  • Spatial data accuracy
  • Spatial data privacy
  • Spatial data security
  • System implementation
  • Data migration
Submission instructions and templates are available at http://2009.foss4g.org/workshops/and http://2009.foss4g.org/tutorials/.

The deadline for workshop / tutorial submissions is March 9, 2009