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
