[Imports] MapQuest translation of Beijing - requesting feedback

[Sam Vekemans]

oops.
Ian is correct, i could have said that :)


Nrcan's CanVec tiles got sliced using the quad-tree tiling system,
where the geographic area contains a max of 20,000 nodes, so any more
than that, increases the chances of conflict.


It's explained on the CanVec wiki page, just how it's done.


Also, further separating the features by feature types allows local
users to 'temporarly claim' work in a local area.


This method, ensures that the community is collaborating.


So, go ahead, make your list of changes locally, then, provide .osm
files, split into small regions and ask the community for help to
merge.


.... Time consuming, yes, quality? .... OSM prefers to build a
community map, over a quality map. A quality gets better, only over
time and more mappers.



cheers,
sam

On 10/26/10, Ian Dees <ian.dees at gmail.com> wrote:
> This looks good. Some suggestions:
>
> 1) Try to do it in geographically small regions. i.e. one city or smallish
> bounding box at a time
> 2) Use an obvious username
> 3) Make the turnaround time quick enough so as to reduce conflicts (this
> goes hand in hand with #1)
>
> On Tue, Oct 26, 2010 at 2:56 PM, Hardgrave, Roman
> <rhardgrave at mapquest.com>wrote:
>
>> Hello,
>> We are considering doing a translation project to add some westernized
>> names
>> to roads and places in several Asian cities.  We're planning to start with
>> Beijing and see how it goes.  We wanted to get feedback on our plan from
>> the
>> community before we got started.
>>
>> The idea is to add name:en attributes to any Node or Way that has existing
>> data in the name attribute.  Also, if the existing name attribute
>> contained
>> westernized names (rather than native), we'd move that data from the name
>> attribute to the name:en attribute.
>>
>> We'll be providing our translators a spreadsheet where they can add/move
>> the
>> data.  Here's the step by step process on how we're planning to extract
>> and
>> then import the data back into OSM.
>>
>> 1) Export the osm files out of the master OSM data given a bounding box
>>    -Use JOSM, XAPI or the OSM web based export given a bounding box
>> 2) Run a script to chew through the osm file and look for any nodes and
>> ways
>> that have a name attribute but not a name:en attribute.  For those that
>> fit
>> the bill, capture the following data into a csv:
>>    a) Node or Way
>>    b) Node or Way Id
>>    c) Version
>>    d) Name Native
>> 2a) Possibly add functionality to the script to look for westernized
>> charactersets in the native field and either flag it or move it
>> automatically
>> 3) Give the csv to translator.  They translate (via Excel) and then export
>> out a csv:
>>    a) Node or Way
>>    b) Node or Way Id
>>    c) Version
>>    d) Name Native
>>    e) Name English
>> 4) Download the osm data again to get latest set
>> 5) Reform the osm data file with the new translated fields by inserting
>> xml
>> tags for the native and english language attribute for nodes/ways,
>> matching
>> by ID
>>    a) Would check first that the Version is the same before updating
>>    b) Ones with different Versions would be retrieved for manual
>> inspection/resolution
>> 6) Upload via JOSM
>>
>>
>> We have the resources lined up to get started on this soon.  We want to
>> make
>> sure our plan and process look good.  Thank you for any feedback you can
>> provide.
>>
>>
>> Roman Hardgrave
>> Senior Sales Engineer
>> MapQuest
>> rhardgrave at mapquest.com
>>
>> Try out the new MapQuest ­ new.mapquest.com
>>
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/imports
>>
>


-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails