Thanks again Serge!  I think for the most part that cleared everything up :).  Only thing I'm still not so clear on is the tagging.<br><br>> Another question about this is that I<br>
> am working in the U.S., but I would be importing data for a region 
in an<br>
> another country.  Do I follow the tagging system of the U.S. or do I
 follow<br>
> that of the country I am importing for?<br>
<br>
>They should be roughly the same. Can you give me a specific 
example of<br>
>a difference?<br><br>When I look at the U.S. tagging format, I see key-value pairs.  The data I want to map is in China.  When I go to the Hong Kong format I don't see the same type of pairing as I do for the U.S. version...<br>

<div class="im"><br>
> What if that country has different<br>
> tagging systems for different regions and none listed for the 
region of my<br>
> interest?<br>
<br>
</div>>They generally don't. If they do, use the local one.<br><br>The area I want to map in China is Tibet, not Hong Kong.  Should I just use Hong Kong's version?  Or U.S. since I am in U.S.?<br><br>Again many thank you's,<br>
<br>elshae<br><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 1:28 PM, Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com">emacsen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, Jan 18, 2011 at 12:19 PM, IT Intern <<a href="mailto:itintern12@gmail.com">itintern12@gmail.com</a>> wrote:<br>
> Thank you for your response Serge!  This is a very good outline and you are<br>
> very kind to have given me this kind of walk through.  I have read through<br>
> the docs about each part you outlined for me and have some more questions..<br>
<br>
</div>Great.<br>
<div class="im"><br>
> "If you've signed up recently, you've accepted the new Contributor Terms"<br>
> So I believe this means that I should work under OSM's future license<br>
> policy, even though they have not yet made the crossover?<br>
<br>
</div>I'd like to avoid discussing licenses too much since it's a hot topic,<br>
and not in the good way...<br>
<br>
But if you've accepted the CT, the CT handles the licence transition<br>
as far as OSM is concerned. But your organisation must be comfortable<br>
handing this data to OSM and letting it re license it.<br>
<br>
Let me put it to you another way...<br>
<br>
Once you accept the CT and contribute the data to OSM, the data<br>
belongs to the OSM Foundation, and the foundation may re license it.<br>
There are very good reasons for this, but as you might imagine, this<br>
can be somewhat controversial.<br>
<div class="im"><br>
>  Or do I work<br>
> under the current terms for now and then change everything later?  Sorry for<br>
> asking what may seem like dumb questions, but I want to be really sure about<br>
> this :)<br>
<br>
</div>Nothing dumb about this; it's a bit complex.<br>
<br>
The short answer is, as long as you've accepted the CT on behalf of<br>
your organisation and they're okay, you don't have to worry about<br>
licenses again.<br>
<div class="im"><br>
> "If you understand OSM, then you know how we use tags to classify features."<br>
> My data is in a GIS database.  I looked at the tagging section of the docs.<br>
> The way I understood it is that I have to change my database to reflect the<br>
> tags?<br>
<br>
</div>You don't need to change your database to fit our API.<br>
<br>
Let's imagine a fictional database full of historical fountains.<br>
<br>
The table might be "fountains" and there might be a single row called "latlong"<br>
<br>
OSM doesn't care about how the data looks internally, it only cares<br>
about how the data looks when it enters the system, that is a fountain<br>
from your system would need to come in like:<br>
<br>
<node id="-1" lon="..." lat="..." version="1"><br>
   <tag k="amenity" v="fountain" /><br>
</node><br>
<br>
Using our XML schema as per the API documents.<br>
<br>
This example is a little simplified, but you probably get the point,<br>
which is that  OSM  only cares about the data representation as it<br>
enters OSM, not how it's represented inside your own system.<br>
<div class="im"><br>
>  I'm not really sure since I have a lot of columns with entries such<br>
> as place_name, lon, lat, geom, etc.<br>
<br>
</div>In several jobs I've been at, I've had to do data mapping from one<br>
system to another. Maybe one customer has one stream format they<br>
prefer data in, and another is different.<br>
<br>
OSM has its own format, and it would then be your job to map the<br>
fields in your database to ours.<br>
<br>
So for example, "place_name" might become "name", and so on.<br>
<div class="im"><br>
> Another question about this is that I<br>
> am working in the U.S., but I would be importing data for a region in an<br>
> another country.  Do I follow the tagging system of the U.S. or do I follow<br>
> that of the country I am importing for?<br>
<br>
</div>They should be roughly the same. Can you give me a specific example of<br>
a difference?<br>
<div class="im"><br>
> What if that country has different<br>
> tagging systems for different regions and none listed for the region of my<br>
> interest?<br>
<br>
</div>They generally don't. If they do, use the local one.<br>
<div class="im"><br>
> As for importing data, I saw it mentioned somewhere that there is a test<br>
> database for OSM that I can work with to ensure my actual import goes<br>
> right.  Is this so?<br>
<br>
</div>dev06 is meant for experimentation of software and you are encouraged<br>
to use it as such. The data in it is throwaway, so be aware that what<br>
you see won't look like normal OSM data.<br>
<div class="im"><br>
> Other than that is there a place I can show my .osm<br>
> files for moderation and checked by an OSM team or professionals alike that<br>
> will ensure me that my pending import data will benefit OSM?<br>
<br>
</div>That's an excellent question. I've been suggesting this for a long<br>
time. My suggestion is join the import list, write up a wiki page on<br>
it, share it, share the osm, wait for feedback. If you don't get any,<br>
go for it. If you do get feedback, try to address it.<br>
<br>
This process may seem slow, but as someone who has personally caused<br>
import pain, and spent a long time cleaning it up, I can tell you it's<br>
well worth it.<br>
<div class="im"><br>
>  Also I saw<br>
> that you said that mass data imports are not favored.  What constitutes as a<br>
> "mass import" as opposed a more normal/manageable one?<br>
<br>
</div>Any automated process is generally disfavoured.<br>
<div class="im"><br>
> As for the XML/.osm format, isn't there a tool from the FWTools suite,<br>
> something like ogr2osm that will correctly convert my GIS to .osm?  I am<br>
> guessing that even with such a tool, that I might have to edit/clean-up the<br>
> .osm files a bit, but I assume there has to be many tools out there to do<br>
> the bulk of the conversion...<br>
<br>
</div>Ivan said he'd help you with that. Ivan knows what he's doing.<br>
<div class="im"><br>
> I truly appreciate all your kind help and assistance with this.  I don't<br>
> know what I would do if it wasn't for you guys :)<br>
<br>
</div>It's our pleasure to help.<br>
<font color="#888888"><br>
- Serge<br>
</font></blockquote></div><br>