<div dir="ltr">Ian,<br><br>I haven't used JOSM much at all. Thanks for pointing out the fact that it can further massage data. I will look into it.<br><br>One issue I forgot to mention is the coordinate transformation from State Plane projected coordinate system that's used by some (all?) local data to OSM's WGS84. Seems like GDAL needs pretty explicit help on with setting the right osr.SpatialReference(). I had no luck getting GDAL to evem recognize the WKT from the .PRJ file that came as part of the Shapefile data set. Do you know of an elegant way to handle this? Maybe pass an EPSG number as a command line argument?<br>
<br>Shapefile points should be easy to convert to OSM POI, no?  No comment on multipolygons; I have very little experience with OSM and GIS in general.<br><br>BTW, if you need help testing the script, I can run it on my county's data. I know enough Python to be dangerous. I thought I'd start with Point data like libraries, police stationes, etc. and work my way up to street centerline data.<br>
<br>Victor<br><br><br><div class="gmail_quote">On Fri, Jul 25, 2008 at 9:55 AM, Ian Dees <<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="Ih2E3d">On Fri, Jul 25, 2008 at 6:10 AM, Victor Snesarev <<a href="mailto:victor.snesarev@gmail.com" target="_blank">victor.snesarev@gmail.com</a>> wrote:<br></div><div class="gmail_quote">
<div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><br>First of all, it seems that a generic Shapefile-to-OSM script is impossible to write without writing a conversion application around it.</div></blockquote></div><div><br>My thought on this is that there are two use cases:<br>

<br>1. Convert a relatively small (a county or city's worth of road centerlines, for example) shapefile to OSM, open it in JOSM, and use the find/tag features of JOSM to apply OSM tags and upload to OSM servers.<br><br>

2. Mass import of huge sets of shapefiles (all of the TIGER data, for example). In this case, a set of rules mapping shapefile data fields to OSM key/value pairs could be pre-set via a rules file or in code.<br><br>So far, I think (1) would work just fine in most cases.<br>

 </div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">Street centerline data is stored as a PolyLine shape type in the Shapefile, while police station locations are Points, and parks are Polygons. Is that right?</div>

</blockquote></div><div><br>This is true. There are dozens of different geometry types in a shapefile. So far, the shp_to_osm.py script knows about lines and polygons. Points and multipolygons are next and would cover the geometry types I've seen in most shapefiles.<br>

 </div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">One more point... Can anyone comment on advantages/dissadvantages of adding an OSM export plugin for something like <a href="http://www.mapwindow.org/" target="_blank">MapWindow</a>, <a href="http://www.qgis.org/" target="_blank">QGIS</a>, <a href="http://mapnik.org/" target="_blank">Mapnik </a>or some other GIS application?</div>

</blockquote></div><div><br>I was thinking about writing a plugin for the ogr2ogr app, which would then allow is to do all sorts of exports/imports on OSM data. Shapefile <-> OSM, OSM <-> PostGIS, etc.<br><br>
-Ian<br>
</div></div></div>
</blockquote></div><br></div>