[OSM-dev] Software development - most pressing issues

Brett Henderson brett at bretth.com
Fri Nov 30 01:13:29 GMT 2007


Martijn van Exel wrote:
> Hi all,
>
> The Dutch chapter is writing up a funding proposal to send out soon.  
> In it, we are going to include a section for software development. The  
> underlying idea is to be able to catalyse software development  
> necessary to ensure smooth operation of OpenStreetMap in the near  
> future. To give this some body, I'd like your thoughts on what the  
> most pressing issues currently are.
>
> We discussed this in the Dutch context which is kind of specific, in  
> that the Dutch dataset is almost complete now thanks to tha AND data  
> that was incorporated back in September:
> * The Dutch OSM dataset attractive for commercial use on a nationwide  
> basis. Therefore, we need to anticipate availability / performance  
> issues. Part of this is to be accomplished in software.
> * The focus shifts - away from acquiring new data to improving the  
> quality of existing data. This creates the need for a kind of 'mobile  
> lightweight JOSM'.
>
> But these are just some issues that arise in the specific Dutch  
> context. I really would like to see a kind of 'top 3' of concrete  
> software-related issues to include in the funding proposal. To make a  
> strong case, the issues should be as SMART[1] as possible.
>
> Thanks for your input on this.
>
> [1] http://en.wikipedia.org/wiki/SMART_%28project_management%29
>   
My 2 cents:
* Atomic commits and database referential integrity.  May not seem like 
a big deal currently but it provides a basis for building more advanced 
functionality.
* Checkin changesets.  Combined with atomic commits, it becomes possible 
to group multiple changes into a single commit.  This provides the basis 
for several features including rollback and bulk upload.  It would also 
simplify osmosis changeset generation.  It would be great to be able to 
identify all changes in an area over the last week, identify all edits 
by a particular user, etc.
* Rollback functionality.  Potlatch is already making inroads here from 
a small scale editing point of view, but I think more advanced rollback 
allowing large scale changes to be modified will need database changeset 
support.
* Faster turnaround on rendering times.  Obvious technical challenges 
aside, turnaround time on map updates is one of OSMs primary advantages 
over competitors so it would be nice to see us maximise this advantage.





More information about the dev mailing list