I don't think koordinates or geocommons offer what we need, though: a way for a mapper to take the results of merging and use them while mapping in JOSM or Potlatch.<div><br></div><div>I don't think the right thing to do is to merge the data and then upload it wholesale (i.e. with a script) into OSM.<br>
<br><div class="gmail_quote">On Wed, Dec 8, 2010 at 10:41 AM, Sam Vekemans <span dir="ltr"><<a href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm still early in the game, but it looks like <a href="http://koordinates.com" target="_blank">koordinates.com</a> could<br>
be the best holding house for this.<br>
.... all that needs to be done on <a href="http://koordinates.com" target="_blank">koordinates.com</a> side is to have the<br>
option to zoom into an area and export as .osm files.<br>
<br>
<br>
I'll be loading a bit more samples of shp files so to see what it's like.<br>
<br>
<br>
<br>
I think <a href="http://geocommons.com" target="_blank">geocommons.com</a> is planning on supporting .osm files as a<br>
export option.... its just too early to tell who will be the biggest<br>
and best :)<br>
<br>
<br>
If there is a 3rd .shp file website out their, i'd be happy to hear of it.<br>
<br>
<br>
cheers,<br>
sam<br>
<br>
<br>
p.s. on the new zealand mailing list, folks are wrattling their brains<br>
to get something.<br>
... and for canvec it's the ommissions and remissions that can be done<br>
at canvec data source level.<br>
<br>
<br>
Still no breakthrough afaik ...<br>
<div><div></div><div class="h5"><br>
On 12/8/10, Ian Dees <<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>> wrote:<br>
> With TIGER 2010 starting to roll out we need to think about how to offer<br>
> some way of comparing OSM with arbitrary datasets.<br>
><br>
> Here are my thoughts so far:<br>
> 1) User uploads a shapefile<br>
> 2) User selects attribute(s) in the shapefile to use for matching with OSM<br>
> data (i.e. a road name or tiger identifier or something)<br>
> 3) System performs a geospatial match (including the attribute(s) the user<br>
> specified in step 2) on OSM data in the area of the shapefile<br>
> 4) System renders a map with three layers: a) data in reference but not<br>
> found in OSM, b) data in OSM but not found in reference, c) data in both<br>
><br>
> Based on (4), mappers can modify the OSM data to more-closely match the<br>
> geometry or meta-data of the reference data set. A more complicated version<br>
> of this tool could allow the mapper to accept wholesale changes in geometry<br>
> or attributes into the OSM dataset (removing or manipulating the existing<br>
> data).<br>
><br>
> This is all pretty tricky, but I'd love to hear other people's opinions.<br>
><br>
> On Wed, Dec 8, 2010 at 10:06 AM, Mike N. <<a href="mailto:niceman@att.net">niceman@att.net</a>> wrote:<br>
><br>
>> I have obtained a set of road centerlines from a US county that has been<br>
>> published in the public domain. I would like to use this to correct the<br>
>> OSM roads for that county, since the TIGER data was one of the "poor<br>
>> alignments" that we are so familiar with. In addition, the road names<br>
>> have<br>
>> all been changed for E911 consistency. This file is likely even newer<br>
>> than<br>
>> the 2010 TIGER centerlines.<br>
>><br>
>> I have used Ian's shp-to-osm to begin looking at the data.<br>
>><br>
>> 1. Does anyone have a rules file for a typical municipal road<br>
>> centerlines shape file conversion? I started to develop this, but<br>
>> can't<br>
>> believe no one has done this before.<br>
>> 2. Is it good to preserve TIGER tags for untouched roadways, or just<br>
>> delete and replace them? The geometry is so far off that it is easier to<br>
>> delete and replace.<br>
>><br>
>> Usual import disclaimers -<br>
>><br>
>> Any relations will be preserved.<br>
>> Any existing road alignment edits will be preserved (such as for<br>
>> interstates)<br>
>> Any existing attribution will be preserved (speed limits, traffic lights,<br>
>> etc)<br>
>> Corrected data will be manually stitched to existing data at borders or<br>
>> pre-edited roads.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Imports mailing list<br>
>> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
>> <a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
>><br>
><br>
<br>
<br>
</div></div><font color="#888888">--<br>
Twitter: @Acrosscanada<br>
Blogs: <a href="http://acrosscanadatrails.posterous.com/" target="_blank">http://acrosscanadatrails.posterous.com/</a><br>
<a href="http://Acrosscanadatrails.blogspot.com" target="_blank">http://Acrosscanadatrails.blogspot.com</a><br>
Facebook: <a href="http://www.facebook.com/sam.vekemans" target="_blank">http://www.facebook.com/sam.vekemans</a><br>
Skype: samvekemans<br>
IRC: irc://<a href="http://irc.oftc.net" target="_blank">irc.oftc.net</a> #osm-ca Canadian OSM channel (an open chat room)<br>
@Acrosscanadatrails<br>
</font></blockquote></div><br></div>