Re: [Talk-us] Clark County, Nevada Street Center Line data

[Karl Newman]

On Fri, Jul 25, 2008 at 1:11 PM, Joseph Scanlan <[EMAIL PROTECTED]> wrote:

> On Thu, 24 Jul 2008, Ian Dees wrote:
>
> > make sure that the data is better than the data that was already
> > imported from TIGER.
>
> The data is quite good and gets updated weekly.  So...  I don't want to
> treat this as a one shot conversion.  Updates should be part of my plan.
>
> 



> Updates:
>
> 1   create scl.osm preserving attributes as ccgis: tags
> 2   extract working.osm from planet.osm with the same
>bounding box as scl.osm
> 3   create add.osm, delete.osm, and change.osm by comparing
>ccgis: tags in scl.osm and working.osm
> 4   review changes.osm with JOSM and upload
> 5   review add.osm with JOSM and upload
> 6   process delete.osm (but how?)
>

Osmosis can create the diffs for you, if you keep a local copy of scl.osm
(after you upload), then do a diff with a new, updated copy of scl.osm. That
should help reduce your update burden.

Karl
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

Re: [Talk-us] Clark County, Nevada Street Center Line data

[Joseph Scanlan]

On Thu, 24 Jul 2008, Ian Dees wrote:

> make sure that the data is better than the data that was already 
> imported from TIGER.

The data is quite good and gets updated weekly.  So...  I don't want to 
treat this as a one shot conversion.  Updates should be part of my plan.

I've downloaded the SCL and converted it to lat/lon to use in xastir
http://www.xastir.org/
My current copy is a little old.  I'll find my notes and get a fresh 
copy.

> I can help you with the convert shapefile to .osm step, as I am slowly
> working on the SHP -> OSM script mentioned previously on this list.

Thanks.  I'm an old Fortran programmer who's learned to hack together 
Java, PERL. etc. but I've never tried reading/writing shapefiles or XML. 
Should be fun to learn.

Initial import:

STRCLASS is the street class as defined by Clark County GIS (CCGIS).

1   for each STRCLASS in county shapefile
2   create scl.osm preserving attributes as ccgis: tags
3   extract working.osm from planet.osm with the same
bounding box as scl.osm
4   remove ways from scl.osm that are already in working.osm
(by comparing ccgis: tags)
5   use JOSM to replace TIGER ways with ways from scl.osm
6   upload changes
7   relax until planet.osm is updated
8   next STRCLASS

Step 1 may not be as simple as iterating through STRCLASS.  The CCGIS 
data doesn't clearly identify motorways.  I plan to do these in the 
first iteration by selecting on STRNAME.  (That's what inspired step 4.)

Steps 2, 3, and 4 should be automated with a script.

Updates:

1   create scl.osm preserving attributes as ccgis: tags
2   extract working.osm from planet.osm with the same
bounding box as scl.osm
3   create add.osm, delete.osm, and change.osm by comparing
ccgis: tags in scl.osm and working.osm
4   review changes.osm with JOSM and upload
5   review add.osm with JOSM and upload
6   process delete.osm (but how?)

-- 
-
Joseph Scanlan   http://www.qsl.net/n7xsd
+1-702-455-3679   http://n7xsd.dyndns.org
[EMAIL PROTECTED] (work)   (not work) [EMAIL PROTECTED]
-

So he went inside there to take on what he found.
But he never escaped them, for who can escape what he desires?
   --Tony Banks of Genesis
in "The Lady Lies"

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

Re: [Talk-us] intertwined ways in Austin TX

[Alan Millar]

> Does anyone with knowledge of the script have time to fix things in
> Austin?

Yes, I will take care of it.  Thanks for finding it.

- Alan



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

Re: [Talk-us] Shape to OSM conversion

[Morgan Ress]

Morning everyone,

Thanks to Victor for bringing this back up.

I've been trying to get Ian's script working, but the sad truth is I
just don't know python. At some point, I'll try and learn it, but
today's not that day.

In my experience working with GIS data from a few sources even in one
city, Victor's comments about fields in the being created by whoever
created the dataset are correct - if there are standards, no one I know
follows them. Also, he's right about the data types - shapefiles come in
three flavors, point (x,y) line, and polygon. I do think that having
street shapes in one polygon file and street information (name, one way,
last time resurfaced, etc) in a separate line shapefile (street center
line) is common if not standard.

In the short term, if those of you who know python well could comment
the script and provide some basic documentation, I would have more of an
idea about how to get the script working on my data. For example, making
it clear where I specify which field has the street name.

In the longer term, a QGIS plugin to work with or export to OSM would be
amazing. I'd love to help out however I can, but again, I don't know how
to write python scripts.

-Morgan

> 
> First of all, it seems that a generic Shapefile-to-OSM script is
> impossible to write without writing a conversion application around it.
> The reason I say this is because shapefile feature attributes are set by
> whoever is compiling the data, and they are probably quite different
> between counties/locations. For example, my county's street centerline
> data has attributes like "STNAME", "STYPE", "DIR_SUF", etc. Some other
> county's data will have completed different names. Seems to me that this
> makes it impossible to automate the task of mapping Shapefile attributes
> to OSM tags. The conversion script user would have to specify this
> mapping. Is that right?
> 
> The other issue I suspect is that the conversion process would be
> different for street centerline data versus, say, police station
> location or parks and recreation areas. 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?
> 
> I am not saying that it is not possible to write a fairly complete
> application to analyze the shape file and present the user with choices
> for mapping feature attributes to OSM tags. I just want to get others'
> views on the issues involved in a conversion script.
> 
> One more point... Can anyone comment on advantages/dissadvantages of
> adding an OSM export plugin for something like MapWindow
> , QGIS , Mapnik
> or some other GIS application?
> 
> Victor
> 
> 
> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

Re: [Talk-us] Shape to OSM conversion

[Victor Snesarev]

Ian,

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.

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?

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.

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.

Victor


On Fri, Jul 25, 2008 at 9:55 AM, Ian Dees <[EMAIL PROTECTED]> wrote:

> On Fri, Jul 25, 2008 at 6:10 AM, Victor Snesarev <
> [EMAIL PROTECTED]> wrote:
>
>>
>> First of all, it seems that a generic Shapefile-to-OSM script is
>> impossible to write without writing a conversion application around it.
>>
>
> My thought on this is that there are two use cases:
>
> 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.
>
> 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.
>
> So far, I think (1) would work just fine in most cases.
>
>
>> 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?
>>
>
> 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.
>
>
>> One more point... Can anyone comment on advantages/dissadvantages of
>> adding an OSM export plugin for something like 
>> MapWindow,
>> QGIS , Mapnik or some other GIS
>> application?
>>
>
> 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.
>
> -Ian
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

Re: [Talk-us] Shape to OSM conversion

[Ian Dees]

On Fri, Jul 25, 2008 at 6:10 AM, Victor Snesarev <[EMAIL PROTECTED]>
wrote:

>
> First of all, it seems that a generic Shapefile-to-OSM script is impossible
> to write without writing a conversion application around it.
>

My thought on this is that there are two use cases:

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.

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.

So far, I think (1) would work just fine in most cases.


> 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?
>

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.


> One more point... Can anyone comment on advantages/dissadvantages of adding
> an OSM export plugin for something like MapWindow,
> QGIS , Mapnik or some other GIS
> application?
>

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.

-Ian
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us

[Talk-us] Shape to OSM conversion

[Victor Snesarev]

There've been several discussions on converting shapefile data form local
governments to OSM. Like Ian, I've been hacking around with Python looking
to convert local county data to OSM. So, I wanted to start a separate thread
to discuss the process. Here it goes...

First of all, it seems that a generic Shapefile-to-OSM script is impossible
to write without writing a conversion application around it. The reason I
say this is because shapefile feature attributes are set by whoever is
compiling the data, and they are probably quite different between
counties/locations. For example, my county's street centerline data has
attributes like "STNAME", "STYPE", "DIR_SUF", etc. Some other county's data
will have completed different names. Seems to me that this makes it
impossible to automate the task of mapping Shapefile attributes to OSM tags.
The conversion script user would have to specify this mapping. Is that
right?

The other issue I suspect is that the conversion process would be different
for street centerline data versus, say, police station location or parks and
recreation areas. 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?

I am not saying that it is not possible to write a fairly complete
application to analyze the shape file and present the user with choices for
mapping feature attributes to OSM tags. I just want to get others' views on
the issues involved in a conversion script.

One more point... Can anyone comment on advantages/dissadvantages of adding
an OSM export plugin for something like MapWindow,
QGIS , Mapnik or some other GIS
application?

Victor
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us