[osmosis-dev] Upload-Task
Hello Brett, I have the Java-code required to open a changeset and upload an OSC-file. Are you interested in an upload-change-task for Osmosis? It can do all kinds of things with changes but currently python is required to upload them. So this is the one feature missing for a consistent set of tasks. ;) Marcus ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Problem using Osmosis (PluginLifecycleException)
On Wed, Nov 11, 2009 at 4:03 PM, Marcus Wolschon
marcus.wolsc...@googlemail.com wrote:
On Tue, Nov 10, 2009 at 11:03 PM, Brett Henderson br...@bretth.com
wrote:
Changing osmosis.bat is not the problem but how can I do an entry
Does
anybody know how to build a classpath list based on the jars contained in
a
directory within ant?
http://ant.apache.org/manual/CoreTasks/jar.html
That would be the attribute sub-element.
Unless I'm misunderstanding the attribute element that's not quite what I
meant.
I already have the following snippet in build.xml.
manifest file=build/binary/jar.txt
attribute name=Main-Class
value=org.openstreetmap.osmosis.core.Osmosis/
attribute name=Built-By value=${user.name}/
attribute name=Implementation-Title value=Osmosis Library/
attribute name=Implementation-Version
value=${project.version} (${TODAY})/
attribute name=Implementation-Vendor value=Brett
Henderson/
/manifest
I could add a classpath element, but I don't know how to add it dynamically
so that I don't have to hard code the list of jars.
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Problem using Osmosis (PluginLifecycleException)
On Wed, 11 Nov 2009 22:37:27 +1100, Brett Henderson br...@bretth.com
wrote:
http://ant.apache.org/manual/CoreTasks/jar.html
That would be the attribute sub-element.
Unless I'm misunderstanding the attribute element that's not quite what I
meant.
I already have the following snippet in build.xml.
manifest file=build/binary/jar.txt
attribute name=Main-Class
value=org.openstreetmap.osmosis.core.Osmosis/
attribute name=Built-By value=${user.name}/
attribute name=Implementation-Title value=Osmosis
Library/
attribute name=Implementation-Version
value=${project.version} (${TODAY})/
attribute name=Implementation-Vendor value=Brett
Henderson/
/manifest
I could add a classpath element, but I don't know how to add it
dynamically
so that I don't have to hard code the list of jars.
I haven't tried it but this could do the trick:
http://stackoverflow.com/questions/1456852/ant-commands-to-print-fileset-into-a-file-one-match-per-line
fileset id=libs dir=../lib/test
include name=*.jar /
/fileset
property name=jars refid=libs /
manifest file=build/binary/jar.txt
attribute name=Main-Class
value=org.openstreetmap.osmosis.core.Osmosis/
attribute name=Built-By value=${user.name}/
attribute name=Implementation-Title value=Osmosis
Library/
attribute name=Implementation-Version
value=${project.version} (${TODAY})/
attribute name=Implementation-Vendor value=Brett
Henderson/
attribute name=Class-Path value=${jars}/
/manifest
Now how to change ; into : in ${jars}
But maybe it works anyway.
Marcus
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
[osmosis-dev] Relations with 65k members
Hi, we just had a problem with diff updates because someone created relations with more than 65k members and Osmosis tries to store them as a char which raised an exception. I did a quick hack that would simply drop the excessive members with a warning: http://www.remote.org/frederik/tmp/remove_excessive_members.diff I'm not checking that in. I thought about simply patching Osmosis to use an integer but was informed by Jon Burgess that osm2pgsql (which is next in my toolchain) would carp on 65k members as well so I didn't bother - especially as it turned out that the relations in question were an error in somebody's automated import and have been meanwhile fixed by Lennard (they contained the same element over and over). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Relations with 65k members
Hi, Frederik Ramm wrote: I thought about simply patching Osmosis to use an integer but was informed by Jon Burgess that osm2pgsql (which is next in my toolchain) would carp on 65k members as well Turns out osm2pgsql in its default config allows only up to 32767 members. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
[OSM-dev] Minute Diffs
I've been trying to get a copy of the OSM data set into a postgres database so I can extract some statical info to help with hopefully one day search etc. Broadly speaking I've been following the instructions at http://wiki.openstreetmap.org/wiki/Minutely_Mapnik except I'm skiping osm2psql and using osmisis to import the data directly. eg osmosis -q --read-change-interval --write-pgsql-change I would like to start with just part of the database due to space, and processor limitations and have preloaded the data using bzcat planet-latest.osm.bz2 | osmosis-0.31/bin/osmosis --read-xml-0.6 file=- --log-progress --bb left=-11 right=2 top=63 bottom=49 --write-pgsql-dump enableBboxBuilder=yes enableLinestringBuilder=yes nodeLocationStoreType=TempFile Is this doable what do I need to do to get the diff to import without error. (If its possible at all) If its not I'll have to find a faster computer with more space which is not the simplest job in the world (250G is currently the largest single disk in the office and it looks like the postgres database for the whole planet is 500G+ currently (including indexes etc)) If any one knows how much space I would need that might help too. Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Minute Diffs
Peter Childs schrieb: I've been trying to get a copy of the OSM data set into a postgres database so I can extract some statical info to help with hopefully one day search etc. Broadly speaking I've been following the instructions at http://wiki.openstreetmap.org/wiki/Minutely_Mapnik except I'm skiping osm2psql and using osmisis to import the data directly. I'm using osm2psql with osmosis to import the minutely replicating diffs and get I no errors. /sql/diffs/osmosis-trunk/bin/osmosis --rri workingDirectory=. --wxc - \ 2 $OSMOSISLOG | /usr/bin/osm2pgsql --append --slim --cache 1024 \ --username gis --style /sql/planet.osm/wikimedia.extended.style \ --verbose - 12 2 $PSQLLOG As osmosis is putting the changesets into osm2pgsql via pipe you should be able to plug another osmosis task in between to cut out your bbox. If any one knows how much space I would need that might help too. You might want to apply for a toolserver account: https://wiki.toolserver.org/view/Account_approval_process I'm maintaining a (nearly) up2date database in mapnik postgis format, but with extended fields (phone, fax, url, opening_hours etc.). Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Minute Diffs
2009/11/11 Peter Körner osm-li...@mazdermind.de: Peter Childs schrieb: I've been trying to get a copy of the OSM data set into a postgres database so I can extract some statical info to help with hopefully one day search etc. Broadly speaking I've been following the instructions at http://wiki.openstreetmap.org/wiki/Minutely_Mapnik except I'm skiping osm2psql and using osmisis to import the data directly. I'm using osm2psql with osmosis to import the minutely replicating diffs and get I no errors. /sql/diffs/osmosis-trunk/bin/osmosis --rri workingDirectory=. --wxc - \ 2 $OSMOSISLOG | /usr/bin/osm2pgsql --append --slim --cache 1024 \ --username gis --style /sql/planet.osm/wikimedia.extended.style \ --verbose - 12 2 $PSQLLOG As osmosis is putting the changesets into osm2pgsql via pipe you should be able to plug another osmosis task in between to cut out your bbox. The only issue with that is that it thows a nasty error Task 2-bb does not support data provided by default pip sotred at level 1 in the default pipe stack. osmosis -q --read-change-interval workingDirectory=$DIR/minute -bb left=-11 right=2 top=64 bottom=49 --write-pgsql-change database='osm' user='peter' I'm now trying to import the change sets without the bb but with only part of the original data (Which probably means I'll gather new stuff outside the original square but hopefully it will not blow up in my face for a while since it has plenty of hard drive space...) Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
On Wed, Nov 11, 2009 at 6:41 AM, Lars Francke lars.fran...@gmail.com wrote: There are a few questions that probably need answering first and I hope we can start a discussion about this: - Am I correct in assuming that there are no general objections from the OSM server folks against such a dump? (Which would render the rest of this E-Mail useless ;-) the response has always been if someone writes it, and it's good, we'll run it :-) - Is anyone else currently working on this? for some values of working, yes. it's on my list of things to do for the license change plan - clearly we'll need a full data dump before we can re-license. - Which format should the data be dumped in (3) is the easiest to get done and most easily supported, in my opinion. - Distribution of the data and storage space requirements i have a feeling that the data, while big, won't be so big that the usual method of planet.osm.org + heanet mirror won't work. - Interval of dumps based on back-of-the envelope calculations, a full dump in planet format would take something like 7-10 days to do in parallel with normal server activity. so it couldn't be run every week and would probably be cumbersome to do every month. in my opinion, we should be looking at every 3-6 months. 3) A dump of all OSM elements in OSM format (http://www.openstreetmap.org/api/0.6/node/60078445/history) this is my favourite method as well. the easiest approach would be to modify planet.c to dump the full history, instead of just the current_* tables. note that brett has been working on option (2) by using osmosis to dump very historical diffs going back to the inception of the database. you can see the experimental results in http://planet.openstreetmap.org/history/ for my money, if we do both (2) and (3), then we cater for all consumers, and in a standard format. the output of the COPY command, while good for backups, isn't really suited to dumping the information that we have in the planet (given there will be edits by users who are still not public, etc...) if you want to get started hacking on planet.c then i'm happy to help. otherwise i'm hoping to get around to it by the end of the month, but there are never any guarantees ;-) cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
Hi, Lars Francke wrote: I understand that a lot of this data is available throughout the web using old snapshots and diffs but this comes in outdated formats and is by no way complete or easy to use. Keep in mind that while a full database dump will give you some things that are not in the old planet files, but the reverse is true as well - there is information in the old planet files (pre-0.5) that is not in the database and thus will not be part of a history dump. Specifically this applies to pre-0.5 way history. This is not really a big deal execpt for those who would hope to make OSM history animations going back farther than API 0.5. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Any OpenStreetMap viewer for Android?
On Tue, Nov 10, 2009 at 09:55:31PM +0100, Stefan Keller wrote: I additionally found MGMaps (available at www.nutiteq.com/libsdk.html), but it's actually 'only' an SDK lib. After some confusions about the license I got convinced that it's GPL for non-commercial use. I added it at the bottom of the afore mentioned Wiki page. There is no such thing as GPL for non-commercial use. They claim on their web page somewhere that their SDK is Open Source, but it's not. See the FAQ here: http://www.nutiteq.com/faq.html#What_are_your_licensing_options Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
I understand that a lot of this data is available throughout the web using old snapshots and diffs but this comes in outdated formats and is by no way complete or easy to use. Keep in mind that while a full database dump will give you some things that are not in the old planet files, but the reverse is true as well - there is information in the old planet files (pre-0.5) that is not in the database and thus will not be part of a history dump. Specifically this applies to pre-0.5 way history. This is not really a big deal execpt for those who would hope to make OSM history animations going back farther than API 0.5. I had not thought of that. When I first used OSM, segments were long gone so I tend to forget those. There are a few planet dumps from those time but none before 060403 and no diffs (which would be required to fully reconstruct the history). While I'm of course interested in the most complete history possible I don't know if this data would be easy to integrate. As I understand it all the old segments that weren't part of a way were converted to a way and all 0.4-ways were just migrated to 0.5-ways (segments to node reference). I suppose segments that were part of at least one way were not converted to a way? So we'd need to: - Find the segments for previously unwayed segment-ways and incorporate their history into the way. As the new way starts at version 1 this would have to be a hack (version 0, counting backwards or something like that). - For ways we'd need to find the history data of the segments they were made of and merge that into the history of the way, again requiring versions before 1 I don't know if it is worth the trouble but on the other hand it would be nice to have a complete history. Especially as this would have to be done only once. But as I said: My knowledge of pre 0.5 times is limited at best and I'd be happy if you/someone else could tell me if what I wrote makes sense. I'd certainly be willing to have _a look_ at this, too. Thanks for pointing this out! Lars ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
Andy, Ultimately the formation of a mini project is probably needed. Input from those like yourself willing to work on it and the will and time from others who would need to support the work, including sysadmins. I had hoped that this could be (re-)solved rather unbureaucratic and without the need to involve the Wiki :) The wiki tends to drag discussions on I'm sure its all possible, but like so many things in OSM it also has to be practical and realistic to have any real chance of gathering momentum. Your and the other answers suggest to me that it is practical and realistic, thanks! At the moment I'm fully motivated to do what I can/need to get the data I want. Hopefully that's enough momentum. Cheers, Lars ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
Hi, Lars Francke wrote: I had not thought of that. When I first used OSM, segments were long gone so I tend to forget those. There are a few planet dumps from those time but none before 060403 and no diffs (which would be required to fully reconstruct the history). No, diffs only show the changes between two points in time, not what happened in between; so they cannot be used to fully reconstruct history. While I'm of course interested in the most complete history possible I don't know if this data would be easy to integrate. No, it would probably be hard. As I understand it all the old segments that weren't part of a way were converted to a way and all 0.4-ways were just migrated to 0.5-ways (segments to node reference). I suppose segments that were part of at least one way were not converted to a way? I think so too, but I am unsure what happened to tagged segments. Also we used to have lots of unordered ways where a number of segments were part of a way but not in a sorted order. Sometimes they weren't even contingent and thus had to be split in multiple ways when 0.5 was introduced. Also, we used this deliberately to model areas with holes (two chains of segments, one clockwise, one counter-clockwise, being part of the same way - that was your area with a hole!). These would have to be retro-fitted into multipolygons for every point in history. It is not difficult to do it once but to do it for two points in history and hope to assign the resulting changes to the same virtual relation id is... a challenge. - For ways we'd need to find the history data of the segments they were made of and merge that into the history of the way, again requiring versions before 1 Yes, we briefly thought about something like that when we did the 0.4-0.5 migration (a synthesized history if you will) but dropped the idea due to its complexity. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
- Am I correct in assuming that there are no general objections from the OSM server folks against such a dump? (Which would render the rest of this E-Mail useless ;-) the response has always been if someone writes it, and it's good, we'll run it :-) That's all I wanted to hear :) (3) is the easiest to get done and most easily supported, in my opinion. Once more: That's all I wanted to hear! - Distribution of the data and storage space requirements i have a feeling that the data, while big, won't be so big that the usual method of planet.osm.org + heanet mirror won't work. I'll have to rely on your word there but that sounds good too. One thing less to worry about. - Interval of dumps based on back-of-the envelope calculations, a full dump in planet format would take something like 7-10 days to do in parallel with normal server activity. so it couldn't be run every week and would probably be cumbersome to do every month. in my opinion, we should be looking at every 3-6 months. Sounds reasonable enough. I don't know how much demand there is for this data anyway. note that brett has been working on option (2) by using osmosis to dump very historical diffs going back to the inception of the database. you can see the experimental results in http://planet.openstreetmap.org/history/ for my money, if we do both (2) and (3), then we cater for all consumers, and in a standard format. the output of the COPY command, while good for backups, isn't really suited to dumping the information that we have in the planet (given there will be edits by users who are still not public, etc...) Indeed, (2) _and_ (3) would be the best solution! I had noticed the history diffs but didn't know their status. Thanks Brett for clarifying it! if you want to get started hacking on planet.c then i'm happy to help. otherwise i'm hoping to get around to it by the end of the month, but there are never any guarantees ;-) The last time I've programmed in C is quite a while back (same goes for C++ which is used by the postgres part of the dump program if I'm not mistaken)...so I'll have a look at it but I'm more comfortable with Java (or Python, Erlang, Ruby, ...). So I'll see what I can do and inform you about my progress. The worst that can happen is that we have two working solutions for the same problem. Not too bad :) I had brief discussions with Brett about Osmosis and incorporating certain changes into it so I've spent quite some time in its source code. Having said that: I probably won't program this as a new task for Osmosis but as a standalone program as this probably won't be used widely and doesn't justify the extra work required to incorporate this into Osmosis. Thanks for your response. I'm hopeful now that this can be done! Lars ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM in a C apps
Look at http://www.novopia.com/emerillon/ On Tue, Nov 10, 2009 at 8:57 PM, Atton Jonathan jonathan.at...@gmail.com wrote: Hello, I am not an openstreetmap user, consequently I do not know a lot about it. I am written a C application and I wish to integrate a map. My application is free (license LGPL), consequently I plan to use a free map and openstreetmap is the perfect choice for this. I am a developer in the project Enlightenment (windows manager + set of libraries + application) and I want to write a gui widget for the project and my application. Today, what is the best way to display OSM in a C application ? I saw Mapnick, I need to look deeper in this way but boost is required and I preferred to avoid big dependencies. What type of data should I use, download a jpeg/png directly ? or the data and create the map (this is what Mapnick does if I understand well) ? -- Regards. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
On Wed, Nov 11, 2009 at 1:29 PM, Lars Francke lars.fran...@gmail.com wrote: I had brief discussions with Brett about Osmosis and incorporating certain changes into it so I've spent quite some time in its source code. Having said that: I probably won't program this as a new task for Osmosis but as a standalone program as this probably won't be used widely and doesn't justify the extra work required to incorporate this into Osmosis. just remember that new code = new bugs ;-) cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
I had not thought of that. When I first used OSM, segments were long gone so I tend to forget those. There are a few planet dumps from those time but none before 060403 and no diffs (which would be required to fully reconstruct the history). No, diffs only show the changes between two points in time, not what happened in between; so they cannot be used to fully reconstruct history. That's why I like the new replicate diffs. Has anyone done - and kept - a complete database dump before migrating from 0.4 to 0.5 or is the history (at least partially) lost? As I understand it all the old segments that weren't part of a way were converted to a way and all 0.4-ways were just migrated to 0.5-ways (segments to node reference). I suppose segments that were part of at least one way were not converted to a way? I think so too, but I am unsure what happened to tagged segments. Also we used to have lots of unordered ways where a number of segments were part of a way but not in a sorted order. Sometimes they weren't even contingent and thus had to be split in multiple ways when 0.5 was introduced. Also, we used this deliberately to model areas with holes (two chains of segments, one clockwise, one counter-clockwise, being part of the same way - that was your area with a hole!). These would have to be retro-fitted into multipolygons for every point in history. It is not difficult to do it once but to do it for two points in history and hope to assign the resulting changes to the same virtual relation id is... a challenge. Thanks for the history tour. I didn't know all that. Sounds a bit like the Wild West of OSM :) But I can't quite follow the multipolygon problem. I thought that _every_ old segment has been migrated to 0.5 in one way [sic!] or another and I would only prepend the history I can find to these existing ways. Am I thinking too simple here? - For ways we'd need to find the history data of the segments they were made of and merge that into the history of the way, again requiring versions before 1 Yes, we briefly thought about something like that when we did the 0.4-0.5 migration (a synthesized history if you will) but dropped the idea due to its complexity. I can certainly appreciate that decision. I just want to understand what would be needed and decide if it is worthwhile to do something about it or not. Lars ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
Lars Francke [mailto:lars.fran...@gmail.com] Sent: 11 November 2009 1:16 PM To: Andy Robinson (blackadder-lists) Cc: OpenStreetMap Dev Subject: Re: [OSM-dev] Complete history of OSM data - questions and discussion Andy, Ultimately the formation of a mini project is probably needed. Input from those like yourself willing to work on it and the will and time from others who would need to support the work, including sysadmins. I had hoped that this could be (re-)solved rather unbureaucratic and without the need to involve the Wiki :) The wiki tends to drag discussions on The community likes to be kept informed of developments and there may be others out there that wish to help with stuff or have a real interest in the form and function of what is done. Only a small number of the OSM community read the dev list. Putting stuff on the wiki doesn't necessarily mean you are asking for discussion, but rather it's a means of communicating what you are doing and providing a conduit for the community give feedback. Cheers Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Please add the walkingpapers description to the scan-info section in the HTML source for JOSM
On Wed, Nov 11, 2009 at 8:17 PM, Frederik Ramm frede...@remote.org wrote: Ævar Arnfjörð Bjarmason wrote: That's a non sequitur actually, the git-svn frontend is conduit between SVN and has its limited uses but converting between centralized and distributed version control is always going to be a case of casting a square peg into a round hole. I don't have much git clue but some may remember that JOSM was in git, briefly, when Gabriel Ebner did his work on dropping segments. Conceptually, what would be the difference between putting JOSM on git and putting it on the project-wide SVN altogehter? If the main advantage of git is that it would become easier for anyone to contribute even if no maintainer has the time to review a patch, then the same could be achieved by going the same way that almost all other OSM applications go and put it on svn.openstreetmap.org - couldn't it? Sure, it could be moved to the main OSM SVN. But it has been my understanding that the main JOSM developers like keeping the gates to their main repository fairly closed, and in that case if they used a distributed version control system they could have their cake and eat it too. Very few people could be given access to the main repository (the ones official .jar files get compiled from) but everyone would have access to version control. If you're unfamiliar with distributed version control I think the best way to explain it is that things which now happen outside version control in the project will be brought into the loop. For instance now people who don't have commit access may be submitting huge patches to trac without commit messages, and often many successive patches as it gets reviewed. If the project were using dvcs (correctly) those patchsets would be developed in someone's local repository along with commit history until they could be merged into the mainline. At one point I had two pending patches to JOSM and wanted to develop a third one. I had already submitted them to trac but for each change I had done: svn diff [files relevant to the patch] change-a.patch rm [files relevant to the patch] svn up If the project had been using git I could have commited each of those changes to their own local branch while they were pending inclusion. Also, if we were to use git, would we depend on a third-party service like github, or is git also usable (in a sensible way) without such a site? Presumably if JOSM were to switch to something else it would want to use something like the Trac plugin for Git to provide integration to josm.openstreetmap.de. But using github certainly has a lot of advantages. Also with git you're never really dependent on third-party hosting. Even if a project is using github and github is taken over by flesh-eating aliens tomorrow getting everyone back on track is just a matter of turning any checked out copy (because they all have full history) into a hosted git:// repository and sending a message to the mailing list telling everyone to commit to that. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
