Re: [udig-devel] GSoC 2012 - Introduction

[Carol Hansen <carolbhansen@xxxxxxxxx>]

Hi Craig,

Thank you for your informative and detailed response! It is much appreciated.

Your idea for an OSM editor that can separate out individual layers is great. OSM does tend to seem a bit cluttered if you're trying to concentrate on only certain similar features. 

I am definitely interested in route analysis, pertaining to not only driving, but other modes of transportation as well, for example biking. I'm inspired by Google Maps' bike route option, which actually collects route suggestions from users based on their input of safety hazards, construction, and other characterisitcs that may affect someone's decisions to take a certain bike route. (Cyclestreets has something similar using Potlach2, that includes lots of other pertinent data about the route.

http://www.cyclestreets.net/journey/). Expanding on the Routing features Davide completed in 2010 and also adding some customization of route features would be a an exciting project.

I am also interested in making improvements on the geoprocessing tools, both back-end and front-end. I would like to get a taste of both back-end and front-end. Being able to USE the data of OSM simply and effectively would make OSM that much more powerful, especially since there is so much data available. Being able to create custom geoprocessing tools and then automate them based on all of the data available is mind blowing to me...and then to be able to render individual layers of the information you need, crazy. 

I will send Davide my ideas  and hopefully we can start coming up with a proper timeline and filter it down to something that is doable by the end of the summer.

Thank you again!

Take care,

Carol

On Sun, Apr 1, 2012 at 5:46 AM, Craig Taverner <craig@xxxxxxxxxx> wrote:

Hi Carol,

Since I mentored the OSM editor project last you which you mentioned before, I thought I should comment on that as well as give my opinions on your email below.

Firstly, Mirco was unfortunately not able to complete the GSoC last year. There was one component, however, that was completed and could conceivably be used for future work, and that was the Dynamic Layers manager. This is kind-of like setting up prepared statements in a database, or creating new views. Mostly the views are filtered subsets of the data. In the case of OSM data, this means, for example, a view that shows only a streetmap, or a major highway map, or a forests polygon layer, etc. The OSM model is a single fully-connected graph of all data so it is actually necessary to set up these views in order to facilitate rendering in a normal layer-based GIS like uDig.

Most normal GIS layers are already separated into layers (eg. a separate shapefile for each layer). This is convenient for rendering, but not convenient for topological analysis. OSM, since it is fully connected, is much better suited to topological analysis. For example, if a street runs along the one edge of a forest polygon, you do not need to try to perform an analysis to learn that the street is running along the forest because the OSM model will actually use the same vertices and edged in the graph to represent the street and polygon. So topological knowledge is already built into the model.

The two GSoC projects we mentored last year were:

• OSM Editor - planned to create a graph editor in uDig for editing the OSM model, and refreshing the normal map rendered layers so that edits could be visualized in rendered form immediately, before later publishing to OSM itself. The work would be mostly visual requiring code in uDig plugins, and a little back-end coding in Neo4j-Spatial. This project did not complete, as mentioned above.
• Geoprocessing on OSM data. In this case the project focused mostly on the back-end, building a library of geoprocessing functions. The project did complete with a library of geoprocessing functions similar in many ways to what you would see in PostGIS. However, it was not completely clear how to differentiate this in a graph-like way, so we did a followup project with Davide taking the lead and coding a new Geoprocessing Pipeline.

Both of the above projects were expected to lead towards improved data mining on OSM. The latter one did, but I would think it primarily laid the groundwork for a much nicer geoprocessing framework, but there are loose ends to close and improvements to be made.

My opinion is that you should consider what kind of project you want, using a similar front-end versus back-end approach to the above two projects from last year. If you are more interested in visual development, primarily in uDig, then something like the OSM Editor would be a natural choice. If you are more interested in data modeling and geoprocessing, then there are many cool things that can be done in the geoprocessing pipeline to make it more powerful and complete. For example, we wish to see Cypher become a more integrated approach for geospatial processing in Neo4j. Another potential project that deals with both the front and back ends would be to build visual tools in uDig for accessing the Geoprocessing pipeline? That would be cool too, and certainly a great match for the idea of 'data mining OSM'.

So, are you more interested in visual development in uDig, or geoprocessing in the back-end? Davide mentioned that he is more experienced in the back-end, but I think he would be able to mentor both types, since he (and you) would receive support from myself and, more importantly, real uDig experts like Jody and Andrea who are always willing to answer questions and give advice.

Now I will try comment on your last email inline:

 

I am not too clear on what a Topology/Network editor is. Is it a functionality allowing users to query, for example, routes or connections (similar to the Google Bike Route feature)?

Since OSM is a fully connected graph, and Neo4j is a true graph database, route analysis is a natural fit here. I did not mention routing above, but that is also a good option for a project. Davide did a prototype routing app in 2010, and so I'm sure we could imagine a much more complete routing project as a GSoC involving both front-end and back-end code.

 

I am trying to get a clear picture of the proposed project we're thinking about so I have a couple questions...(and then hopefully we can start talking about how to put it all together).

1) Essentially, an OSM editor would be a plugin enabling uDig users to download OSM data, edit the data and upload back to OSM? Could this be done by somehow integrating JOSM (Java Open Street Map editor) or would we be creating an editor from scratch?

The idea I had when I proposed the OSM Editor last year was a new graph editor in uDig that worked similar to JOSM with the ability to edit the connected graph like JOSM does, but with the rendered graph layers also visible, and each time you 'commit' your changes, the property rendered layers refresh to reflect the changes. This is different to what you would see with something like potlatch where there is a backing image layer. Instead you would have proper GIS layers with all the config options of the GIS.

2) Neo4j Spatial is essentially a library of java interfaces enabling spatial processes (based on graphical relationships instead of tabular relationshps)?...And for our proposed project, we would be using these interfaces to create new Java classes to plug into uDig, to enable OSM updates and routing capabilties based on connectivity (I took a look at your project from 2010, so shortest path capabilities are already available)?

I think you have the right picture here :-)

Regards, Craig

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel