[OSM-dev] OSM Wishlist

[Iván Sánchez Ortega]

On Viernes, 12 de octubre de 2012 01:58:23 Tom MacWright escribió:
> What do you want to see happen with OSM's software this year? What are the
> tasks which everyone agrees on, but nobody has had the time to tackle?

OK, here's mine:


A diff/patch tool for imported data.


Let me explain.


Assume I imported a dataset, (e.g. Spanish powerplants 2010) a few months (or 
years) ago. I survive the flamewars in imports@, I manage to clean up the data, 
I manage to upload everything without too many validator errors in JOSM. So 
far, so good.

Now, assume a newer version of the same dataset appears on the wild (e.g. 
Spanish powerplants 2012). I want to be able to:


a) Know which data the provider added or deleted, and have those additions and 
deletions uploaded into OSM ("Has the authoritative source added more 
powerplants?")
b) The data provider wants to know what changes the OSM community has done, 
related to the data they provided ("have they changed the boundary of this old 
polygon Igforgot to check?")


I don't know if the way to tackle this problem down is to keep a registry of 
imported data, in order to check newer versions of external datasets with the 
registered older versions of already-imported external datasets, or rely on 
source= tags and version numbers.


Seriously, guys from NMAs would *love* this.







Also.



ogr3osm.

I would love to have the time and resources (or paid time, nudgenudgewinkwink) 
to redo ogr2osm; adding a backtracking-like algorithm to minimise the amount 
of geometries' shared nodes (and their bounding boxes) in memory, in order to 
be able to convert datasets with gazillions of geometries into .osm format. 
Backtracking-like in the sense that the data processing would be done in a 
tree-like fashion, walking through overlapping geometries, processing only 
geometries which have all their nodes already into the list of generated node 
IDs, writing to file and destroying from memory nodes that won't appear again 
because all the overlapping geometries have been processed.

Yes, it sounds like a mouthful. I have a bunch of napkin notes with the 
algorithm written down, though :-)




Also.


Right now, the HOT would greatly appreciate a seeding GUI for MapProxy. Some 
python+openlayers+javascript hacking should do in a couple of weeks. The goal 
being that a user would be able to seed the caches through the development 
server web interface, without needing to edit config files.

Bonus points for a cache configuration GUI.





Cheers,
-- 
Iván Sánchez Ortega <ivan at sanchezortega.es> <ivan at geonerd.org>

¿Donde está el enchufe para el COM4:?