<br><div class="gmail_quote">On Tue, Oct 20, 2009 at 4:07 PM, Ian Dees <span dir="ltr"><<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>></span> 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 class="im">On Tue, Oct 20, 2009 at 5:45 PM, Sam Vekemans <span dir="ltr"><<a href="mailto:acrosscanadatrails@gmail.com" target="_blank">acrosscanadatrails@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote">

<div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
Can you give an example of a situation when you'd need to use multiple<br>
source fields for 1 osm tag?<br>
<br>
Also, if your creating intersecting ways, double check to see that the<br>
nodes are infact connected. (shp-to-osm doesnt connect the ways.<br>
(thats why im not dealing with roads, and leaving it to the shp2osm<br>
script to handle) but it seems all other features are fine though.<br></blockquote></div><div><br>If this is important to you, I can quick release a version of shp-to-osm that does connect ways.<br><br>I have code in the repository now for what I called "glomming". It hasn't shown up in shp-to-osm yet because I don't read the entire data file in to memory before writing it out (so I can read arbitrarily-large shapefiles). In order to do this, I would have to read the entire shapefile in to memory, leading to a restriction on the size of shapefile to convert.<br>


</div></div>
</blockquote></div><br>Interesting,<br>That makes sence, so in order to make the nodes connected, you would need to put the entire file into memory, then connect the ways, then output the file.   (thats the same thing that shp2osm does)  so instead of using a PostGIS database, it would just be quickly saved on memory in the background).  <br>

<br>So perhaps 'C' (connected) version of the shp-to-osm.jar program can be made? ... even if it can only work for 'small' shp files.   I can add it onto the script line so that it would 1st attempt to run this C version, and if it 'fails' (because of the size), it would automatically skip it and move onto the next task.  (or be defaulted to produce a 0meg .osm file which gets omited with the -t option) <br>

<br>to: imports@ list<br>    There ought to be a way that shp files can be 1st 'sliced'..<br>Ie.  (Geographically cut into an arbitrary grid (regardless of the shape of the polygon) 4, 16, 256 or whatever size)  so then each square can be dealt with independently.<br>

.... ya i know it can be done with ArchGIS, but were looking for a command line alternative :)... Also, slicing AFTER processing will  help too.    Is that something that osmosis can do?<br><br>cheers,<br>Sam<br>