Nabble - Talk-US

Re: NHD status?

2009-01-09T10:53:29Z

On Tue, Sep 30, 2008 at 6:52 AM, Ian Dees <ian.dees@...> wrote:

Anyway, to answer your question, I think we first need to:
1) Standardize on FCode -> Tags
2) Keep track of which HUC codes are imported and by whom. (I can start working on this as a wiki page)

I'm starting to look at this (NHD import) again. Check out:

http://wiki.openstreetmap.org/wiki/National_Hydrography_Dataset

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Upcoming mapping parties in the Bay Area and Central Texas!

2009-01-08T11:16:31Z

Mark your calendars, we are hosting more mapping parties in the near
future!

San Francisco: Jan 17th: wiki.openstreetmap.org/wiki/San_Francisco

San Antonio: Jan 24th: wiki.openstreetmap.org/wiki/San_Antonio

Austin: Jan 25th: wiki.openstreetmap.org/wiki/Austin

Cheers!
Sarah

Sarah Manley
Sarah@...
Cell: 631-338-3815
Skype: Sarah_cloudmade
Twitter: SarahManley

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Haverhill, MA missing

2009-01-07T19:56:33Z

On Wed, Jan 07, 2009 at 09:48:38PM -0500, Christopher Schmidt wrote:

> > On Sun, Nov 23, 2008 at 3:02 AM, Dale Puch <dale.puch at gmail.com>
> > wrote:
> > > Just noticed, braintree is also missing, so eotroads_128 and 40
> > > freetown 102
> > > glouchester 107
> > > are not in the completed list of files, but I don't know if that
> > > proves they
> > > were not uploaded or not.
> >
> > Gloucester looks pretty empty. rt.128 imported, interstates appear to
> > havebeen a separate upload, the rest are user entered by "DialH" which
> > makes import more challenging.
>
> eotroads_40 is now in. I did some checking for conflicts, and didn't
> find anything major, but I uploaded over what was there, so I'm sure I
> caused somewhat of a mess. However, given that the buildings are now in
> that area, I figured it was now or never; if I left it, people would
> have started tracing it in.
>
> The fact that something is not in the list of completed files is not
> relevant; that was just my personal management tool, and once I got the
> upload close to done, I stopped moving things around.
>
> I have no problem managing more uploading; i someone tells me what to
> do, I'll make it happen. But I don't want to upload over other peole's
> stuff, so.
>
> Right now, I'm looking at Haverhill: looks like 495 is all there is.
> I'll de-dupe 495 and get that one in.

Freetown didn't go in; there's two major roads that are going thorugh
it, but I'll just toss those. One o them is already duplicated. (hard to
check right now, since the API is down: I'm going with tiles here.)

The two roads in question are SR140 and SR24.

Gloucester is the same, though there is more tracing. Still, the file
has everything that the existing map has.

Once the API is back working, I'm going to:

1. Clear out 24/140 rom freetown, and upload those.
2. Clear out the roads in gloucester, and upload that.

Since I'll probaby sleep before that happens, people can offer
feedback, but I think that's the best way to deal with this particular
problem.

Regards,
--
Christopher Schmidt
MetaCarta

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Haverhill, MA missing

2009-01-07T18:48:38Z

> On Sun, Nov 23, 2008 at 3:02 AM, Dale Puch <dale.puch at gmail.com>
> wrote:
> > Just noticed, braintree is also missing, so eotroads_128 and 40
> > freetown 102
> > glouchester 107
> > are not in the completed list of files, but I don't know if that
> > proves they
> > were not uploaded or not.
>
> Gloucester looks pretty empty. rt.128 imported, interstates appear to
> havebeen a separate upload, the rest are user entered by "DialH" which
> makes import more challenging.

eotroads_40 is now in. I did some checking for conflicts, and didn't
find anything major, but I uploaded over what was there, so I'm sure I
caused somewhat of a mess. However, given that the buildings are now in
that area, I figured it was now or never; if I left it, people would
have started tracing it in.

The fact that something is not in the list of completed files is not
relevant; that was just my personal management tool, and once I got the
upload close to done, I stopped moving things around.

I have no problem managing more uploading; i someone tells me what to
do, I'll make it happen. But I don't want to upload over other peole's
stuff, so.

Right now, I'm looking at Haverhill: looks like 495 is all there is.
I'll de-dupe 495 and get that one in.

Has anyone else look at the other 2?

Regards,
--
Christopher Schmidt
MetaCarta
--
Christopher Schmidt
MetaCarta

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Large-scale Data Imports and Tags on Nodes

2009-01-07T18:10:56Z

On Wed, Jan 07, 2009 at 05:38:34PM -0800, Sam Vekemans wrote:

> I cc'd to talk-ca list, as it's also relevant.
>
> I do see our point Ian, as when i look through, south of the border, i have
> no actual need to be seeing all these extra tags.
> Yes, they are relevant, but only for the person(s) who are using those tags
> for the update program.
>
> So really, all that is needed is the tag that says it's source, and the NID
> tag. .. Since the python script only really needs to know weather or not
> that point/way actually exists. .. from there, it compares to the OSM tags.
> the tag "nrn:datasetName=Ontario" is that Really needed?

I have a different feeling on this. First of all, if errors are found,
knowing where the source data is from -- to the point that you can find
the bytes neccesary to look at what the source was -- can be useful.

Second of all, I think that, within a namespace, extra tags aren't a bad
thing. One of the targets I have for the MassGIS OpenSpace dataset is to
make it possible to take that data back *out* again -- and not just the
OSM improvements to it, but to essentially make it possible to get the
data file that the source came from back out -- with improvements.

To that end, the MassGIS OpenSpace import included *all* o the non-null
tags on the source, so that the data could be recreated.

The cases this doesn't apply to, in my opinion, are the cases when the
elements you are creating -- nodes, usually -- aren't actually included
as seperate, tagged entities in the source. Shapefiles will amost always
have this as the case; they are non-topological, so the *nodes* are just
strings in the shapefile. Turning them into nodes is an OSM task, not a
shapefile one.

> It's only at the GeoBase side that the tag would be useful. ... searching
> for all the roads in the Ontario dataset of the National Road Network. ...
> so the purpose of having this would be;
> 1 - if we wanted to remove all the data (from a planet.osm dump)
> 2 - if we wanted to replace this dataset with a new one, we would have a tag
> to go by.
>
> the tag "is_in=Ontario" would that not say the same thing?

Probably not, but I don't know about the GeoBased data enough to be
sure. At the very least, Mass lakes data extends outside massachusetts
-- and even if you kept the is_in tag, someone might delete it down the
road.

Regards,
--
Christopher Schmidt
MetaCarta

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Large-scale Data Imports and Tags on Nodes

2009-01-07T17:38:34Z

I cc'd to talk-ca list, as it's also relevant.

I do see our point Ian, as when i look through, south of the border, i have no actual need to be seeing all these extra tags.

Yes, they are relevant, but only for the person(s) who are using those tags for the update program.

So really, all that is needed is the tag that says it's source, and the NID tag. .. Since the python script only really needs to know weather or not that point/way actually exists. .. from there, it compares to the OSM tags.

the tag "nrn:datasetName=Ontario" is that Really needed?

It's only at the GeoBase side that the tag would be useful. ... searching for all the roads in the Ontario dataset of the National Road Network. ... so the purpose of having this would be;

1 - if we wanted to remove all the data (from a planet.osm dump)

2 - if we wanted to replace this dataset with a new one, we would have a tag to go by.

the tag "is_in=Ontario" would that not say the same thing?

So the arguments stated are;

1 - filling up the database with extraneous information

2 - increases the size of the file download

That brings us to an excellent point;

We must be sure to "clearly define" the purpose of adding each extra tag. If the tag only serves as a 'cosmetic' tag, it's not needed.

IMO Tags which get imported should do the following;

1 - tell the renderer what the data is and how it relates to existing OSM Map Feature standards

2 - tell the OSM users WHO imported the data

3 - give the python script some cross-referencing tags to 'RoadMatch'

4 - be the same type of tags that the OSM user would place in otherwise, if the imported data was NOT available.

IMO So far, i think the tags we have are fine, but it's worth some discussions. :)

Message: 1

Date: Tue, 6 Jan 2009 11:34:49 -0600
From: "Ian Dees" <ian.dees@...>
Subject: [Talk-us] Large-scale Data Imports and Tags on Nodes
To: Talk-us <talk-us@...>
Message-ID:
<3baad6b80901060934x4ab85375o7b2dcdcc39f3c1d7@...>
Content-Type: text/plain; charset="iso-8859-1"

I don't think it makes sense to put tags on nodes for mega-imports. This
adds tons of extraneous information that fills up the database quite
quickly. It also increases the size of OSM file downloads by a large margin

Is it really a good idea to attribute each node? Let's stick with
attribution on ways. If we're really worried about it, we could do mass
imports with a specific user and give that user a wiki page to describe
where the data came from.

...discuss...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstreetmap.org/pipermail/talk-us/attachments/20090106/2c2a9aa6/attachment.html

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Large-scale Data Imports and Tags on Nodes

2009-01-07T17:23:38Z

(Sorry for replying out of thread; just joined the list.)

I agree that attribution on nodes contained as part of ways is
unneccesary. I've already stopped doing it on current imports, as other
people have noticed, but have no plans at this time to go back and
update the existing seriousoffender (the MassGIS import) to correct its
blatantly stupid behavior in this regard. I would have no problem if
someone else did this.

Regards,
--
Christopher Schmidt
MetaCarta

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Large-scale Data Imports and Tags on Nodes

2009-01-06T09:34:49Z

I don't think it makes sense to put tags on nodes for mega-imports. This adds tons of extraneous information that fills up the database quite quickly. It also increases the size of OSM file downloads by a large margin

Is it really a good idea to attribute each node? Let's stick with attribution on ways. If we're really worried about it, we could do mass imports with a specific user and give that user a wiki page to describe where the data came from.

...discuss...

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Mass Openspace - was Re: Re Entire town missing - Haverhill, MA

2009-01-02T18:14:03Z

...
> It also looks like there may be an updated version of the data set, as well
> as many other layers with POI data that could be added. Mass transit routes
> and stops, schools, libraries, town halls ect. No need to stop mapping MASS
> just because there are great roads already there.

I would personally like to see the OPENSPACE layer from MassGIS imported.
Help people get outdoors :)

See the wiki: http://wiki.openstreetmap.org/wiki/MassGis_Layer_Openspace
and things linked from it for more details.

I'd be happy to work on it, installed some ogx utilities but didn't get very far by myself,
having limited time and knowledge of the tools.

Tim BL
http://wiki.openstreetmap.org/wiki/User:Timbl

Re: US Route Tagging With Relations

2008-12-26T07:21:09Z

Personally, I think putting the US: in front of state routes is going to get confusing. People are oing to think they're looking at US routes and not state routes.

Second, some significant caution will be needed with adding signs. Some signs (mainly toll roads opened after 1989) are copyrighted and could not be used under any circumstances. See the Wikipedia page where this was discussed:

http://en.wikipedia.org/wiki/Wikipedia:Copyright_on_highway_shields

25or6to4

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: TIGER 2008 Data is Out

2008-12-25T11:24:39Z

On Thu, 2008-12-25 at 23:22 +1100, Justin Adler wrote:
> Hi folks,
>
> quick question about this Tiger lines and OSM.
>
> 1) Are there any import scripts out there which are not rails or php?
> something in .NET maybe?

No.

> 2) Do the tiger lines have the following data (which could then be imported into OSM) :
> a) State shapes (eg. California, New York (state), Illinois, etc)
> b) County shapes (eg. Cook County (IL), DuPage County (IL) etc)
> c) City shapes (eg. San Fran, Boston, Chicago, etc.)
> d) Suburbs (eg. Oak Brook (Chicago), Naperville (Chicago), etc)
> e) Neighbourhoods (eg. Tribeca (NYC), Chelsea (NYC)

Yes.

> 3) Does OSM have this data?

Yes.

-- Dave

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: TIGER 2008 Data is Out

2008-12-25T04:22:56Z

Hi folks,

quick question about this Tiger lines and OSM.

1) Are there any import scripts out there which are not rails or php? something in .NET maybe?
2) Do the tiger lines have the following data (which could then be imported into OSM) :
a) State shapes (eg. California, New York (state), Illinois, etc)
b) County shapes (eg. Cook County (IL), DuPage County (IL) etc)
c) City shapes (eg. San Fran, Boston, Chicago, etc.)
d) Suburbs (eg. Oak Brook (Chicago), Naperville (Chicago), etc)
e) Neighbourhoods (eg. Tribeca (NYC), Chelsea (NYC)

Actually, are suburbs and neighbourhoods the same thing?

3) Does OSM have this data?

thanks heaps for any help :)

-Justin-
________________________________________
> On Tue, Dec 23, 2008 at 11:40 AM, Ian Dees <ian.dees@...> wrote:
> > Huzzah! Let's blast away all of the US and start the upload! :-)
> >
> > http://www.census.gov/geo/www/tiger/tgrshp2008/tgrshp2008.html

I really haven't looked at the conversion scripts in a bit. Has anyone
else?

-- Dave

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Fwd: US Route Tagging With Relations

2008-12-24T17:36:45Z

On Wed, Dec 24, 2008 at 4:58 PM, <lordsutch@...> wrote:

Personally I think it's best to let the renderer be as stupid as
possible - some applications might be embedded, for example. Making
the networks location or context-dependent is a recipe for disaster
IMHO.

When I said "custom shield rendering", I meant that currently, both Mapnik and Osmarender lack support for rendering non-trivial shields. I think the most complex thing you can do is to put a colored box around the text box for the name label of a way. I think the map would look a whole lot better if it displayed the actual shield for the locale.

Once we get that figured out, then we can argue about how the renderer should figure out which shield to draw.

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Fwd: US Route Tagging With Relations

2008-12-24T14:58:07Z

Sorry meant to send to all...

---------- Forwarded message ----------
From: lordsutch@...
Date: Wed, 24 Dec 2008 16:56:48 -0600
Subject: Re: [Talk-us] US Route Tagging With Relations
To: Zeke Farwell <ezekielf@...>

Personally I think it's best to let the renderer be as stupid as
possible - some applications might be embedded, for example. Making
the networks location or context-dependent is a recipe for disaster
IMHO.

The beauty of the proposed scheme is that it's easy for the renderer
to pick a generic symbol that is appropriate.

I - interstate shield
US - us shield
MX - Mexico shield
XX:anything - state/province generic (circle/oval)
XX:yy:anything - local generic (rectangle)

For route guidance like text-to-speech or written directions the last
part (split on colon for anything with a colon) can always be used and
will at least make some sense.

I agree it would be nice to have a North American rendering style but
that's not a data issue. And there's a lot of variety even there;
compare MapArt to Michelin to Rand McNally to AAA/Universal to DeLorme
to USGS.

On 12/24/08, Zeke Farwell <ezekielf@...> wrote:

> Yeah we're getting a little ahead of ourselves with the shields. The first
> step is tagging the highways in a standard scheme which would give a
> renderer sufficient data to draw shields. Then someone has to actually
> build a renderer that draws the shields. Thats a whole other can of worms.
>
> I don't think that the Slippy Map on openstreetmap.org will ever draw custom
> shields beyond blue interstate shields, white US highway shields, and white
> ovals for state routes. I think it would be great to have a map with custom
> shields for every state. What we need for that to happen is someone to set
> up a US based Open Street Map renderer. In addition to custom shields, the
> highway colors could be drawn in more US centric way: varying shades of
> red, orange, and yellow with green reserved for toll roads. I think this
> would really help people in the US get involved with OSM because the map
> would look more familiar to them. The main slippy map is never going to do
> this though, because it is international.
>
>
> 2) I don't like the "is_in" approach - the "US:CA" approach seems to offer
>> all the appropriate information in the same place. However, if there was
>> a
>> way to explicitly state that this is a state route, that would help in the
>> situation mentioned above.
>
>
> The "UC:CA" approach does offer all the appropriate information in the same
> place. I don't think that is necessarily desirable though. For example,
> Vermont Route 30 is never called US Vermont Route 30. The network is just
> Vermont, not United States: Vermont. This is even more true for county
> roads. If Windham county in Vermont had it's own numbered routes one would
> not call a route "United States, Vermont, Windham County Route 10". In
> short, I like the "is_in" approach because keeps the network name simple.
>
> I'd rather not have to bother with the "is_in" tag at all. For someone
> mapping there is no confusion as to whether a highway is Canadian Route 10
> or California Route 10 (unless they are really bad at geography), but I
> suppose this could get confusing for the renderers. Ideally, I would say a
> renderer should be smart enough to know where the US Canada boundary is and
> to render routes tagged with "network: CA" as a California route when in
> the US, and as a Canada route when in Canada. I don't know the details of
> how the renderers work though.
>
>
> Zeke
>

--
Christopher N. Lawrence, Ph.D. <c.n.lawrence@...>
Assistant Professor of Political Science
Texas A&M International University
313 LBVSC, 5201 University Blvd
Laredo, Texas 78041-1920

Website: http://www.cnlawrence.com/

--
Christopher N. Lawrence, Ph.D. <c.n.lawrence@...>
Assistant Professor of Political Science
Texas A&M International University
313 LBVSC, 5201 University Blvd
Laredo, Texas 78041-1920

Website: http://www.cnlawrence.com/

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T14:33:52Z

On Wed, Dec 24, 2008 at 1:44 PM, Zeke Farwell <ezekielf@...> wrote:

Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms.

I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international.

2) I don't like the "is_in" approach - the "US:CA" approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above.

The "UC:CA" approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route "United States, Vermont, Windham County Route 10". In short, I like the "is_in" approach because keeps the network name simple.

I'd rather not have to bother with the "is_in" tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with "network: CA" as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though.

Zeke

I've never liked the is_in tag. It seems like a poorly-thought-out kludge, because the contents are not strictly defined, so it's useless for automated parsing. Instead of having the state name in the network tag, why not have network=us_county, state=CA, county=Marin, operator=Marin County, CA or something like that. The operator tag seems appropriate here, but I'm not sure about the contents. Alternate values for network could be us_interstate, us_highway or us_state. The interstate modifier (alternate, business, etc.) could go into a interstate_modifier tag.

Karl

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T13:44:41Z

Yeah we're getting a little ahead of ourselves with the shields. The first step is tagging the highways in a standard scheme which would give a renderer sufficient data to draw shields. Then someone has to actually build a renderer that draws the shields. Thats a whole other can of worms.

I don't think that the Slippy Map on openstreetmap.org will ever draw custom shields beyond blue interstate shields, white US highway shields, and white ovals for state routes. I think it would be great to have a map with custom shields for every state. What we need for that to happen is someone to set up a US based Open Street Map renderer. In addition to custom shields, the highway colors could be drawn in more US centric way: varying shades of red, orange, and yellow with green reserved for toll roads. I think this would really help people in the US get involved with OSM because the map would look more familiar to them. The main slippy map is never going to do this though, because it is international.

2) I don't like the "is_in" approach - the "US:CA" approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above.

The "UC:CA" approach does offer all the appropriate information in the same place. I don't think that is necessarily desirable though. For example, Vermont Route 30 is never called US Vermont Route 30. The network is just Vermont, not United States: Vermont. This is even more true for county roads. If Windham county in Vermont had it's own numbered routes one would not call a route "United States, Vermont, Windham County Route 10". In short, I like the "is_in" approach because keeps the network name simple.

I'd rather not have to bother with the "is_in" tag at all. For someone mapping there is no confusion as to whether a highway is Canadian Route 10 or California Route 10 (unless they are really bad at geography), but I suppose this could get confusing for the renderers. Ideally, I would say a renderer should be smart enough to know where the US Canada boundary is and to render routes tagged with "network: CA" as a California route when in the US, and as a Canada route when in Canada. I don't know the details of how the renderers work though.

Zeke

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T10:48:37Z

On Wed, Dec 24, 2008 at 12:38 PM, Russ Nelson <nelson@...> wrote:

Alan Brown writes:
> 3) There should be a place for people to contribute highway shields - as metadata.

To make life even more interesting, New York State renders placenames
in the Adirondack Park using beige on brown, rather than the usual and
standard white on green. Looks more "woodsy".

First, we need to get one of the renderers to support custom-drawn shields...

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: TIGER 2008 Data is Out

2008-12-24T10:43:06Z

On Tue, 2008-12-23 at 16:33 -0600, Chris Lawrence wrote:
> On Tue, Dec 23, 2008 at 11:40 AM, Ian Dees <ian.dees@...> wrote:
> > Huzzah! Let's blast away all of the US and start the upload! :-)
> >
> > http://www.census.gov/geo/www/tiger/tgrshp2008/tgrshp2008.html
>
> LOL. I am looking forward to taking a look at the data to see if
> it's an improvement for my part of Texas & to see what can be done
> conversion-wise to get as much useful info as possible into OSM.

I really haven't looked at the conversion scripts in a bit. Has anyone
else?

-- Dave

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T10:38:13Z

Alan Brown writes:
> 3) There should be a place for people to contribute highway shields - as metadata.

To make life even more interesting, New York State renders placenames
in the Adirondack Park using beige on brown, rather than the usual and
standard white on green. Looks more "woodsy".

--
--my blog is at http://blog.russnelson.com | Delegislation is a slippery
Crynwr sells support for free software | PGPok | slope to prosperity.
521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom.
Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter).

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T08:43:23Z

A couple thoughts:

1) Commercial data providers have use a "route type" parameter that designates something as an Interstate, Federal Highway, State Highway, County Road, or Farm-to-Market road. This code does not distinguish between states; all state highways have the same "route type". General practice is to use the same highway shield for all states; you don't get the "Beehive" sign for Utah. :)

This is an opportunity for OSM to distinguish itself; if local users contribute Highway signs from their region - down to very specialized signs for something like "Kettle Moraine Scenic Route" in Southeast Wisconsin - they'll have something the commercial vendors don't provide. However, there should be something clearly identify a route as a state, county/parish, farm-to-market road/ whatever, so a default shield could be picked.

2) I don't like the "is_in" approach - the "US:CA" approach seems to offer all the appropriate information in the same place. However, if there was a way to explicitly state that this is a state route, that would help in the situation mentioned above.

3) There should be a place for people to contribute highway shields - as metadata. Respecifying highway shields for every route would be prone to omissions. In the case of "Kettle Moraine Scenic Route" - it's so specialized, it may make sense to apply the sign to the route itself. But having a place to submit a library of highway shields as metadata - that would be good.

From: Zeke Farwell <ezekielf@...>
To: Talk-us <talk-us@...>
Sent: Wednesday, December 24, 2008 7:50:20 AM
Subject: Re: [Talk-us] US Route Tagging With Relations

Chris,

Thanks for putting up that table. Looks great. I have two suggestions:

I think the network identifiers should be simpler. What about this scheme?

Interstate = Interstate signed highway system
US = US signed highway system
[state abbr.] = State signed highway system

TX = Texas
CA = California
OR = Oregon
etc...

County or other networks should just be the county name or TN Secondary, etc...

To avoid duplicate network values (CA stands for California and Canada) we can use the "is_in" key the same way it is used for place names. So a California route relation would have these tags:

network: CA
is_in: United States

Or a county road system in california:

network: Marin Co
is_in: California, United States

This way we don't clutter up the network name, but we keep the differentiating information.

My other suggestion is that I don't thing the symbol key is necessary. I think the renderers should be able to assign a symbol based on the network and is_in tags once they get to that stage. This way they symbols will stay more consistent and we won't get US highway shields that look slightly different throughout the country.

Thoughts?

Zeke

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-24T07:50:20Z

Chris,

Thanks for putting up that table. Looks great. I have two suggestions:

I think the network identifiers should be simpler. What about this scheme?

Interstate = Interstate signed highway system
US = US signed highway system
[state abbr.] = State signed highway system
TX = Texas
CA = California
OR = Oregon
etc...

County or other networks should just be the county name or TN Secondary, etc...

To avoid duplicate network values (CA stands for California and Canada) we can use the "is_in" key the same way it is used for place names. So a California route relation would have these tags:

network: CA
is_in: United States

Or a county road system in california:

network: Marin Co
is_in: California, United States

This way we don't clutter up the network name, but we keep the differentiating information.

Thoughts?

Zeke

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-23T22:29:38Z

On Tue, Dec 23, 2008 at 7:20 PM, Chris Lawrence <lordsutch@...> wrote:
> - ref is reserved for backward compatibility and should follow
> Key:ref's semantics. "number" is used for the bare route identifier
> (e.g. US 7 -> number=7; I-35W -> number=35W) as in Alan's suggestion.

I just realized that this is incorrect; ref can be used for the bare
numbers since nothing is rendering the route numbers from road
relations at present. I fixed the wiki accordingly.

I also wrote up an example of situations where named routes do not
exactly coincide with numbered routes which should satisfy some
concerns expressed (unsigned) on the talk page.

Chris

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Tiger vs. GeoBase

2008-12-23T18:35:29Z

Hi,
Would there be a wiki page which shows users how to:

1 -find the data on the Tiger site for the small region they are working in.

2 how to view the new updated version file (with gpsMapEdit?)

3 how to directly compare the new data with existing OSM (with a wms layer?)

4 how to convert the shape files that you want to use into OSM format.

5 how to tag this new data with the appropriate tags (ref ID /ver 2009 etc.)

6 how to merge it with osm (copy,paste, upload on josm)

Thanks,
sorry if thats already posted: i want to make a simple step-by-step
set of instructions for us in the land of snow.

Happy Holidays,

Sam Vekemans
Across Canada Trails

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-23T17:20:12Z

I have put up a short table with the proposed tagging scheme in the
OSM wiki. I made a few minor changes from Zeke's practice and Alan's
suggestions:

- ref is reserved for backward compatibility and should follow
Key:ref's semantics. "number" is used for the bare route identifier
(e.g. US 7 -> number=7; I-35W -> number=35W) as in Alan's suggestion.
- I changed "directional" to "direction" and permit abbreviation to a
single letter (N/S/E/W) and oddballs if spelled out - this allows
things like INNER, OUTER which are used in several places; QEW in
Ontario is "tabbed" with places rather than directions. (See
http://en.wikipedia.org/wiki/Queen_Elizabeth_Way#Name_and_signage)
- Less prominent vanity/honorary names probably should be tabbed as
_name variants and added to the Key:name page; the proposal allows any
tags listed under Key:name as part of the scheme. More prominent
names (e.g. Hollywood Freeway, Van Wyck Expressway) should just be
tagged as name.
- I added a "symbol" key that includes a URL for a graphical
representation of the route marker. This should be useful for named
routes like the Ohio Turnpike
(http://upload.wikimedia.org/wikipedia/commons/f/f5/OhioTurnpike.svg)
, the Kentucky parkway system, or the Sam Houston Tollway
(http://upload.wikimedia.org/wikipedia/en/2/26/Samhoustontollway.png),
as well as more generic routes.

Here's the link:
http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Tagging_with_relations_.28proposal.29

Chris

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-23T14:52:32Z

Certainly relations would seem to be the way to go with route marking;
we probably should put together something on the wiki that can be
worked on collaboratively, with Alan's proposal as a start. There are
some areas to be fleshed out (primary & secondary state routes in
states like TN and MO; the seven or eight different classifications in
Texas) and I think there might be some useful additions (for example,
Wikimedia has SVG files for many highway markers that we could include
URLs for in the reference tags, including named routes that would be
difficult to make markers for programatically; then Mapnik etc could
just use those with a simplistic fallback), but this is definitely a
good place to start.

"Vanity names" (or honorary names) BTW can be fairly long, although
there is a question of how much value they have - in some areas (e.g.
So Cal, Chicago, NYC) they're what locals call the highways and are
fairly well-signed, but in others they're downright obscure. And some
places it's a mix (in New Orleans, the Westbank, Earhart, and
Pontchartrain expressways are referred to by name, but I doubt anyone
even knows what name I-610 or I-310 have).

Chris

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: TIGER 2008 Data is Out

2008-12-23T14:33:48Z

On Tue, Dec 23, 2008 at 11:40 AM, Ian Dees <ian.dees@...> wrote:
> Huzzah! Let's blast away all of the US and start the upload! :-)
>
> http://www.census.gov/geo/www/tiger/tgrshp2008/tgrshp2008.html

LOL. I am looking forward to taking a look at the data to see if
it's an improvement for my part of Texas & to see what can be done
conversion-wise to get as much useful info as possible into OSM.

Chris

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-23T10:27:51Z

On Tue, Dec 23, 2008 at 10:15 AM, Alan Brown <adbrown1967@...> wrote:

Vanity Name("Hollywood Expy")

Should Vanity names be included, as they usually don't extend the length of the freeway?

I usually get the impression that these vanity names are more a property of short segment of the freeway itself, rather than the route.

I think vanity names are best handled by apply the vanity name to the underlying way.

-Scott

--
Scott Atwood

Cycle tracks will abound in Utopia. ~H.G. Wells

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: US Route Tagging With Relations

2008-12-23T10:15:02Z

I like the idea. In GDF - a (supposedly) standard exchange format for geographic data,
they have the concept of "composite attributes". I think of a relation used in this way is really better described as a composite attribute that can be applied to many elements.

It's best to specify highway routes in a parsed format; in other word, a highway route relationship might have the following tags.

network ("I", "US", "State", etc).
route number ("80")
modifier("ALT","BR","BL","BUS","BYP","CONN","EXT","LINK","LOOP","SCENIC","SPUR",
"TOLL","TPKE","TRUCK")
directional("WB", "EB", "NB", "SB")

Vanity Name("Hollywood Expy")

This approach results in data that's more normalized (i.e., always use "US" instead of "United States", "US Route", "Federal Hwy", etc.). Software could easily interpret it in sophisticated ways (i.e., stick "80" in a highway shield with "alt" above it, or print instructions "Take Alternate Interstate 80 Eastbound"). You can easily test if there's gaps where a route number has not been applied to a single edge (known as "name rice") . If you use the network to specify highway shields, you can get sophisticated and start showing different shields for each state.

It's not without potential difficulties (separate relations for eastbound and westbound lanes? Should Vanity names be included, as they usually don't extend the length of the freeway? If someone changes a tag on a relationship, they have to be sure it's appropriate for every element that's part of the relationship.) But I think this approach helps more than hurt.

-Alan

From: Zeke Farwell <ezekielf@...>
To: talk-us@...
Sent: Tuesday, December 23, 2008 9:36:18 AM
Subject: [Talk-us] US Route Tagging With Relations

Hi Everyone,

I've been thinking that we ought to have a standardized scheme for tagging Interstates, US Highways, State Highways, and any other numbered routes in the United States. The information I've found on the Wiki regarding US Route Tagging suggests that all information should be put into the ref tag. For example, Interstate 95 should be tagged as "ref: I-95", and if Interstate 95 joins interstate 93 and they follow the same road for a while that segment should be tagged as "ref: I-95;I-93". Mapnik then renders the road with a little box containing [I-95;I-93] which does not make for a pretty map. To me it seems cleaner to use the ref tag only for the route number (ref: 95). However, that would mean we lose the information about what network the route is part of. Also, what do we do about the multiple route problem?

The answer is Relations! They are awesome. Mapnik doesn't render route number badges from relations yet, but it will in the future. I have been tagging routes with relations in Vermont for a while now. For example here is the tagging scheme for the US Highway 7 relation:

type: route
route: road
network: US
ref: 7

Once I've made this relation, any Way that should is a part of Interstate 91 I simply make a member of the relation. The tagging scheme for the actual way might look like this:

US 7 (relation)
highway: primary
name: Main St
ref: 7

The ref tag is not even necessary, because the information is stored in the relation, but I've included is because Mapnik doesn't yet render relation reference numbers. The best part is that when US Highway 7 and US highway 2 join for a while the tagging just looks like this:

US 7 (relation)
US 2 (relation)
highway: primary
name: Main St

This solves a number of the problems surrounding the tagging of numbered routes and makes the database much cleaner. It also allows for the future possibility of route numbers being rendered with the proper shield symbol to differentiate Interstate from US Highway form State Highway. I propose that we all start using relations to tag numbered highways in the United States, and when Mapnik eventually gets around to rendering reference numbers from relations, we can stop using the ref tag on ways themselves entirely.

Zeke Farwell
Burlington, VT, USA

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

TIGER 2008 Data is Out

2008-12-23T09:40:43Z

Huzzah! Let's blast away all of the US and start the upload! :-)

http://www.census.gov/geo/www/tiger/tgrshp2008/tgrshp2008.html

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

US Route Tagging With Relations

2008-12-23T09:36:18Z

Hi Everyone,

I've been thinking that we ought to have a standardized scheme for tagging Interstates, US Highways, State Highways, and any other numbered routes in the United States. The information I've found on the Wiki regarding US Route Tagging suggests that all information should be put into the ref tag. For example, Interstate 95 should be tagged as "ref: I-95", and if Interstate 95 joins interstate 93 and they follow the same road for a while that segment should be tagged as "ref: I-95;I-93". Mapnik then renders the road with a little box containing [I-95;I-93] which does not make for a pretty map. To me it seems cleaner to use the ref tag only for the route number (ref: 95). However, that would mean we lose the information about what network the route is part of. Also, what do we do about the multiple route problem?

The answer is Relations! They are awesome. Mapnik doesn't render route number badges from relations yet, but it will in the future. I have been tagging routes with relations in Vermont for a while now. For example here is the tagging scheme for the US Highway 7 relation:

type: route
route: road
network: US
ref: 7

Once I've made this relation, any Way that should is a part of Interstate 91 I simply make a member of the relation. The tagging scheme for the actual way might look like this:

US 7 (relation)
highway: primary
name: Main St
ref: 7

The ref tag is not even necessary, because the information is stored in the relation, but I've included is because Mapnik doesn't yet render relation reference numbers. The best part is that when US Highway 7 and US highway 2 join for a while the tagging just looks like this:

US 7 (relation)
US 2 (relation)
highway: primary
name: Main St

This solves a number of the problems surrounding the tagging of numbered routes and makes the database much cleaner. It also allows for the future possibility of route numbers being rendered with the proper shield symbol to differentiate Interstate from US Highway form State Highway. I propose that we all start using relations to tag numbered highways in the United States, and when Mapnik eventually gets around to rendering reference numbers from relations, we can stop using the ref tag on ways themselves entirely.

Zeke Farwell
Burlington, VT, USA

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Importing Government Data

2008-12-18T22:44:50Z

Cool :)
what can be done is creating a section for all the options for
importing government data - including the ones that were 'mud' but
state 'why' it was rejected.
Also list pending or aproved stuff

I got a start;
disaproved:
blow away data and replace on-mass
-slap on imported data & create 'ghost lines' with existing data
-import data as nodes with reference to what shape/line/point it is,
keeping origional source designations
:cause we want to protect the existing osm data, and place it as a
higher priority
:cause we dont want to fill up the data base with duplicate nodes

pending:
-cordinate locally, copy select elements with a custom script layer
-use wms layer (rendered openlayer slippy map and trace
-write protect imported data (nodes? If a host can be found to donate resource?

approved:
-tracing over josm wireframe
-tracing over imagery
-tracing over free openlayers
-import only if it doesnt exist in the area

Cheers,
Sam Vekemans

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Importing Government Data

2008-12-18T21:05:00Z

Sam Vekemans writes:
> What this did was sparked some major issues that need to be addressed.
> I think this is more important, than going deeper on that rant.

I'm new to the innards of OSM, so I may be saying something stupid or
obvious. Just step on me if I am.

OSM already contains two kinds of data: data entered into OSM, and
data imported into OSM from elsewhere.

Of the data imported into OSM, there are two kinds: data "thrown over
the wall" to OSM, and data from an entity which wishes to cooperate
with OSM. When the entity wishes to cooperate with OSM, the course is
clear: when someone edits a node which originated with the entity,
make a note, and pass it back to them. When next they hand over data,
replace all data which originated with the entity -- even if edited by
an OSM editor -- with the update from the entity.

If the cooperative entity uses the OSM edit, it's because they felt it
was right. If they don't use the edit, then they think it was a
mis-edit. If they keep getting the same ignored edit back, then maybe
there's something wrong with their data verification procedures?

Of the data "thrown over the wall", again, we can make two
distinctions: one-time data imports, and data of which we expect
updates. The one-time data import we can treat as a gift to OSM just
as we do all the other volunteer improvements. Import it (dealing
with existing data -- a different problem), edit it, and life goes
on.

The really big problem is data that gets imported, where the source of
the data doesn't want our edits back, and where they continue to make
changes and make new data available to OSM (this approximates the
situation with TIGER, which is of interest to me.)

One possiblity is to write-protect that data. That seems like
anathema to me. What's the point in having read-only data in a
publicly-maintained editable database? All we would be doing is
making it easy for OSM-using software to access that data. We're
telling our users "screw you, we don't want your edits", because
that's what the source entity is telling us. But in a sense
write-protecting the data is merely reflecting the reality that user
edits aren't a part of that data.

On the other hand, perhaps the solution is to treat OSM edits as a
patch to the data that comes from the source. When an update comes
along, only delete the previous data that haven't been edited.
Whatever's left will need hand fixing; either to delete the (wrong)
new data or to delete the current edit. (But that would also mean
undeleting deleted nodes from the older data, and marking them as
having been deleted -- this to allow deletion of similar nodes in the
matching updated data).

Am I on the right track, or am I off in the weeds?

--
--my blog is at http://blog.russnelson.com | Delegislation is a slippery
Crynwr sells support for free software | PGPok | slope to prosperity.
521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom.
Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter).

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Importing Government Data

2008-12-18T19:32:06Z

Hi all,
Such great feedback from my latest 'rant: importing GeoBase nodes'
Thanks :)
What this did was sparked some major issues that need to be addressed.
I think this is more important, than going deeper on that rant.

I created a new wiki page "Importing Government Data"
http://wiki.openstreetmap.org/wiki/Importing_Government_Data

This is a way for us all can try to summerize the issues, and answer
the questions that would (most likely) be asked from any country /
region considering importing government data.

The section i didn't expand on is about the scripts used in actually
importing the data these can be shown on the page. (hopefully people
can help out) http://wiki.openstreetmap.org/wiki/Government_Data_Import_Script

Because there are a lot of overlap in the past discussions, hopefully
this page will be able to compare the issues from TIGER & AND, as well
as the other import projects (that i'm not aware of)

I hope that i touched on most of the issues raised.

Please to edit the wiki page, and reply back, as comments are how this
project will keep going :)

I'll get back to you all when i figure out a better solution than the
'nodes import' idea. :)

Cheers,
Sam Vekemns
Across Canada Trails

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

Re: Road classification

2008-12-17T17:56:12Z

Hi,

I'm a member in New Jersey and I've usually reserved any classifications for roads that have any numerical designation assigned to them. In New Jersey, I designate trunk roads sparingly, and hardly ever for roads maintained by the county (with some exceptions for longer 500-series county highways); these are usually isolated roads or roads with more than one carriageway but do not fit the state definition of a freeway. (The Palisades Interstate Parkway, any toll roads, and roads that are recognised by the state as freeways e.g. NJ 495 (this has NOT been an interstate since the 1980's; only the portion of 495 east of Manhattan is an interstate), NJ 42, NJ 55, NJ 90, NJ 3, NJ 19, NJ 21, and NJ 24 are granted motorway status.) Primary highways usually consist of state highways that run parallel to a trunk road or connect one or more large communities, most 500-series county highways, and a few county-specific highways (which usually are in the 600-700 range). Secondary roads are almost always either county-specific highways or state routes that are left over from a re-routing of a major highway; tertiary designations are reserved for all other numbered highways. Unnumbered highways, unless the governing municipality receives monies from the county directly for their maintenance or they form a dedicated or well-used link between designated roads, receive unclassified or residential designations irrespective of length.

This scheme was devised primarily for New Jersey and may not apply the same way in other states.

CrystalWalrein

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

REMINDER: OPENSTREETMAP SACRAMENTO MAPPING PARTY 12/20 & 12/21!!!

2008-12-17T16:41:30Z

Hello all!

The OpenStreetMap Sacramento Mapping Party is this weekend at The
Temple Coffee House in central Sacramento. There will be lots of
hiking-mapping, urban-mapping and bike-mapping that can be done, but
if the weather doesn't agree with you, we can always spend the weekend
doing a little Armchair Mapping in Potlatch!

Details are here:
http://wiki.openstreetmap.org/wiki/Sacramento
http://www.meetup.com/OpenStreetMap-Sacramento/

Venue:
Temple Coffee House
1014 10th St
Sacramento, CA 95814
916.443.4960
http://www.templecoffee.com

Cheers,

Brandon Aguirre
Community Development
CloudMade

503.998.1567
Skype: bragpdx
brandon@...
www.cloudmade.com

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us