Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Apollinaris Schoell]

On Mon, Feb 8, 2010 at 6:00 PM, Richard Welty wrote:

>
>  between this, and some comments on the wiki made by NE2 on the 
> Talk:Interstate
> Highway relations
> page, i suspect we're setting up for some spectacular results due to
> hardheaded non-cooperation:
>
> in this case it doesn't matter yet. no tool uses this info. as long as
someone does the hard work adding roads to route relations it's well spend.
changing the ref/network tags is a simple task as soon agreement is reached.



> "i 'm not going to sign up for a third place to discuss the content of a
> second place (this wiki) which governs the main place (OSM)
>
> " ...but if consensus building all takes place in these various
> back-channels, I truly will get no input until I make the changes, and then
> be reverted
>
> we need to do better than this. anyone can edit the wiki, but also anyone
> can edit the map.
>
>
democracy isn't perfect. but is there a better system?



> richard
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Richard Welty]

On 2/8/10 8:06 PM, Apollinaris Schoell wrote:



anyone can edit the wiki. I can't remember there was an agreement that 
is the right thing to do. As far as I know there is no renderer or 
other tool using the ref/network tags from the relation. And for that 
reason I didn't really care if it makes sense or not.


between this, and some comments on the wiki made by NE2 on the 
Talk:Interstate Highway relations
page, i suspect we're setting up for some spectacular results due to 
hardheaded non-cooperation:


"i 'm not going to sign up for a third place to discuss the content of a 
second place (this wiki) which governs the main place (OSM)


" ...but if consensus building all takes place in these various 
back-channels, I truly will get no input until I make the changes, and 
then be reverted


we need to do better than this. anyone can edit the wiki, but also 
anyone can edit the map.


richard

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Frederik Ramm]

Hi,

Richard Welty wrote:
> there is a major disconnect between what people think is "right" and 
> what the wiki calls for. 

Welcome to OSM ;-)

There is also in many cases a major disconnect between what *is* right 
and what the Wiki calls for, as well as a disconnect between what the 
Wiki calls for and what people actually map.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-us] Fwd: [Warning: Potential Flamewar] Clarifying InterstateRelations

[Nakor]

On 02/08/2010 08:14 PM, Apollinaris Schoell wrote:

> same for me, Josm has good support for sorting and relations and
> checking for gaps. also the relation analyzer will flag them without
> errors then. this helped me so much when I tried to fix routing problems
> and a road is disconnected because 2 nodes on top of each other or very
> small gaps in a road.
> One can always create a super relation to collect both directions into
> one relation.
> 

You may want to try a tool I am developping  (DISCLAIMER: beta version,
may fail ... but feedback welcome) to analyse a relation. Handles "1
relation for both directions", roundabouts, child relations and even "1
relation for 4 directions" (see MI 5:
http://toolserver.org/~nakor/relation.fcgi?relation=252428 )

Thanks,  N.

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Chris Hunter]

On Mon, Feb 8, 2010 at 8:21 PM, Apollinaris Schoell wrote:

>
>
> On Mon, Feb 8, 2010 at 5:07 PM, John Smith wrote:
>
>>
>>
>> Why does there need to be 2 relations for this?
>>
>> besides editing convenience a relation is directed and sorted since API
> 0.6 You can see it as a route to follow from start to end. For bus routes
> this is a must. 2 relations may use the same road in different directions.
> on a highway ref one can argue this is not needed but it's still a good
> idea.
>
>

Another thing to remember is that the relation analyzer and relation
browsers don't support super-relations *yet*.  My gut feeling is that if we
start using super-relations in a consistent manner, it's more likely that
the analyzer (and hopefully the API) will begin supporting them
consistently.

In the long run, using super-relations to create relation hierarchies would
allow us to separate physical attributes of a way (or node) from the logical
attributes of a route.

 ___
>> talk mailing list
>> t...@openstreetmap.org
>>
>> http://lists.openstreetmap.org/listinfo/talk
>>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: [Warning: Potential Flamewar] Clarifying InterstateRelations

[Richard Welty]

On 2/8/10 8:01 PM, Chris Hunter wrote:



Moving back to one of my original questions, I think Nakor was the 
only one to respond to the 2 relations per state (1 relation each way) 
vs 1 relation with rolls per state question.


The Diff code is a little tangled, but from the WIKI, it looks like 
only interstates I-24, I-26, I-84 were merged from 2-relations into 
1-relation with roles.  The rest of the system still has the relation 
numbers listed in the WIKI.  From what I can see, it looks like 
there's no clear winner between the two systems, although quite a few 
Interstates are still missing supers.


I'm happy to use either method, but one of the reasons why I prefer 
the 1-relation-per-direction method is that it lets me quickly find 
areas that need to be split into dual carriageways.
i prefer using one relation per direction, and that's what i've been 
doing. if the consensus should
sway the other way, i won't engage in a lot of public whining about it, 
though.


richard

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

Re: [Talk-us] Fwd: [Warning: Potential Flamewar] Clarifying InterstateRelations

[Apollinaris Schoell]

>
> I'm happy to use either method, but one of the reasons why I prefer the
> 1-relation-per-direction method is that it lets me quickly find areas that
> need to be split into dual carriageways.
>

same for me, Josm has good support for sorting and relations and checking
for gaps. also the relation analyzer will flag them without errors then.
this helped me so much when I tried to fix routing problems and a road is
disconnected because 2 nodes on top of each other or very small gaps in a
road.
One can always create a super relation to collect both directions into one
relation.

>
> Chris Hunter
> DiverCTH
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Apollinaris Schoell]

>  there is a major disconnect between what people think is "right" and what
> the wiki calls for. from
>
> http://wiki.openstreetmap.org/wiki/Interstate_Highways_Relations
>
> we see:
>
> network=US:I, US:I:BUSINESS, US:I:DOWNTOWN, US:I:FUTURE  Required.
> Business, downtown and future routes have their own signage
>
> and
>
> ref=* Required. ex. 90
>
> and many people have been busy building relations to fit this
> specification.
>
> from
> http://wiki.openstreetmap.org/wiki/United_States_Numbered_Highway_Relations
>
> network=US:US
> ref=* ex. 20
>
> and so forth.
>
>
>
>  anyone can edit the wiki. I can't remember there was an agreement that is
the right thing to do. As far as I know there is no renderer or other tool
using the ref/network tags from the relation. And for that reason I didn't
really care if it makes sense or not.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Fwd: [Warning: Potential Flamewar] Clarifying InterstateRelations

[Chris Hunter]

On Mon, Feb 8, 2010 at 6:30 PM, Richard Welty wrote:

>
> there is a major disconnect between what people think is "right" and what
> the wiki calls for. from
>
>
Agreed.  One of the reasons I started this discussion was to make sure that
what the wiki calls for is still "right".  As far as rendering the shields
go, I think we should stick with the established tagging scheme and let
whoever writes the parser worry about stripping the network=US: out of US:*
.


> http://wiki.openstreetmap.org/wiki/Interstate_Highways_Relations
>
> we see:
>
> network=US:I, US:I:BUSINESS, US:I:DOWNTOWN, US:I:FUTURE  Required.
> Business, downtown and future routes have their own signage
>
> and
>
> ref=* Required. ex. 90
>
> and many people have been busy building relations to fit this
> specification.
>
> from
> http://wiki.openstreetmap.org/wiki/United_States_Numbered_Highway_Relations
>
> network=US:US
> ref=* ex. 20
>
> and so forth.
>
>
> Moving back to one of my original questions, I think Nakor was the only one
to respond to the 2 relations per state (1 relation each way) vs 1 relation
with rolls per state question.

The Diff code is a little tangled, but from the WIKI, it looks like only
interstates I-24, I-26, I-84 were merged from 2-relations into 1-relation
with roles.  The rest of the system still has the relation numbers listed in
the WIKI.  From what I can see, it looks like there's no clear winner
between the two systems, although quite a few Interstates are still missing
supers.

I'm happy to use either method, but one of the reasons why I prefer the
1-relation-per-direction method is that it lets me quickly find areas that
need to be split into dual carriageways.

Chris Hunter
DiverCTH
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US Chapter temporary Board Nomination

[Adam Schreiber]

> I accept the nomination to run for the temporary board of the US Chapter of 
> OSM.

I've been an active mapper for almost 3 years.  I've mapped
extensively in the Clemson, SC area and less so around my new home in
VA, but I'm working on it.

I'm a member of the GNOME foundation and have been active in Free
Software for the past 10 years.  I'm the co-maintainer of the seahorse
and seahorse-plugins GNOME modules.  Last summer, I was one of GNOME's
Google Summer of Code admins.

At Clemson U I was a founding member of its LUG, CLUG, and an active
member and multiple time board member.

As a board member, in addition to handling the tasks of starting up
our foundation chapter, I would like to look to the role of the
foundation in the future and OSM's use outside of the current
community.

Cheers,

Adam

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Richard Welty]

On 2/8/10 5:57 PM, Apollinaris Schoell wrote:

quite. the format for ref in relations is very clear, for example


network=US:I
ref=95


Don't think this is clear. US:I is wrong, the network is only I. Any 
consumer application can figure out that it is in US by itself. as an 
example mkgmap currently supports custom shields and does it based on 
the way refs. But with US:I an application has to filter the US: 
specifically for this kind of network which isn't used anywhere else.
if you think the state, country info is needed as a tag use is_in or 
an addr:* tag
combining different values in a single tag makes it too complicated to 
consume data.
there is a major disconnect between what people think is "right" and 
what the wiki calls for. from


http://wiki.openstreetmap.org/wiki/Interstate_Highways_Relations

we see:

network=US:I, US:I:BUSINESS, US:I:DOWNTOWN, US:I:FUTURE  Required. 
Business, downtown and future routes have their own signage


and

ref=* Required. ex. 90

and many people have been busy building relations to fit this specification.

from 
http://wiki.openstreetmap.org/wiki/United_States_Numbered_Highway_Relations


network=US:US
ref=* ex. 20

and so forth.



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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Frederik Ramm]

Hi,

Apollinaris Schoell wrote:
> if you think the state, country info is needed as a tag use is_in or an 
> addr:* tag

I think that addr:* tags should really only used for things that have an 
address.

Streets don't usually have an address; you would not refer to the fact 
that a certain street is in a certain citiy etc. as "the street having 
an address", or would you?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Apollinaris Schoell]

quite. the format for ref in relations is very clear, for example

>
> network=US:I
> ref=95
>
>
Don't think this is clear. US:I is wrong, the network is only I. Any
consumer application can figure out that it is in US by itself. as an
example mkgmap currently supports custom shields and does it based on the
way refs. But with US:I an application has to filter the US: specifically
for this kind of network which isn't used anywhere else.
if you think the state, country info is needed as a tag use is_in or an
addr:* tag
combining different values in a single tag makes it too complicated to
consume data.



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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations

[Matthias Julius]

Jeffrey Ollie  writes:

> On Mon, Feb 8, 2010 at 1:13 PM, Matthias Julius  wrote:
>> Jeffrey Ollie  writes:
>>
>>> What's more annoying is that he is changing the names/refs.   From
>>> what I understand the ref is supposed to be only the
>>> interstate/highway number (e.g. "90" or "80") and not "I 90 (MN)".
>>
>> And I don't like this at all.  First, this seems to be different than
>> how this is handled in many other places in the world.  From what I
>> have seen in Europe there is always the complete designation how it is
>> found on highway shields used in the ref tag.
>
> I don't know if you have travelled much in the US and I've never been
> to Europe, but US road signs are pretty minimal:
>
> http://en.wikipedia.org/wiki/File:I-80.svg
> http://en.wikipedia.org/wiki/File:US_69.svg
> http://en.wikipedia.org/wiki/File:Iowa_3.svg
>
> The color and shape of the sign is used to distinguish different types
> of routes.

On the shields, yes.  But everyone calls 'I 75' just that and not 'the
highway 75 on a blue shield'.

>> Second, separating out the highway system requires the data consuming
>> application to know how to piece things back together.  Otherwise, a
>> shield on a map for example with just a "25" in it is pretty limited in
>> use.
>
> Again, the color and shape of the shield is used to distinguish different 
> routes

So if a renderer puts the correct shield on a highway that is
certainly helpful.  But, if it does not know about the particular
tagging schema I would prefer that it puts 'I 25' on ther instead of
just '25'.  My point is that the ref tag should contain the complete
reference to the object and not require the consideration of another
tag.

>
>> Third, I consider a reference containing just the number to be
>> incomplete.  IMHO, the ref tag should contain the complete designation
>> of a piece of highway.  This also makes it easier to search for this.
>
> That's why I set the name tag on the relation to something a little
> more descriptive.

IMHO it is wrong to set the name tag if the highway does not really
have a name.

>
> Obviously, this scheme works only in the US, which is why the
> "network" tag is used to distinguish US routes from those in other
> countries.

The network tag is certainly useful to make it easier to distinguish a
German 'A 4' from a British 'A 4' for example.

Matthias

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Matthias Julius]

"Mike N."  writes:

>> Second, separating out the highway system requires the data consuming
>> application to know how to piece things back together.  Otherwise, a
>> shield on a map for example with just a "25" in it is pretty limited in
>> use.
>
>   After / if a generalized shield solution is in place, a 25 placed on an 
> 'Interstate' shield is quite descriptive.

But it required every application that is to deal with US data to know
about it.

> It avoids the need for the renderer or consumer to parse out the
> number.

Which is quite trivial to do.

>
>> Third, I consider a reference containing just the number to be
>> incomplete.  IMHO, the ref tag should contain the complete designation
>> of a piece of highway.  This also makes it easier to search for this.
>
>   To search, just search for both the network and route tags.  It's just as 
> though the information was placed in separate database columns.

Which makes it much more complicated if the application used for
searching does not support the schema.

Matthias

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

Re: [Talk-us] FCC Antenna Structure Import

[Jeffrey Ollie]

On Mon, Feb 8, 2010 at 3:25 PM, Anthony  wrote:
> On Mon, Feb 8, 2010 at 12:47 PM, Jeffrey Ollie  wrote:
>>
>>    
>
> By the way, what is the datum for the elevation figure?

I don't believe that it is specified explicitly, but the latitude and
longitude are in NAD83 so I'm guessing that the elevation is the same.
 I convert the latitude and longitude to WGS84 using the GDAL Python
bindings, I should probably figure out if converting the elevation is
as easy as adding a Z component when I do the conversion.

-- 
Jeff Ollie

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

Re: [Talk-us] FCC Antenna Structure Import

[Anthony]

On Mon, Feb 8, 2010 at 12:47 PM, Jeffrey Ollie  wrote:

>
>

By the way, what is the datum for the elevation figure?
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] FCC Antenna Structure Import

[Anthony]

On Mon, Feb 8, 2010 at 12:47 PM, Jeffrey Ollie  wrote:

>
>


> v="
> http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp?regKey=2645662
> "/>
>

I'd say this is redundant, and would lose the url (doesn't seem very
permanent anyway).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] FCC Antenna Structure Import

[Alan Mintz]

At 2010-02-08 09:47, Jeffrey Ollie wrote:
>The FCC maintains a database of antenna structures which includes an
>approximate geographic location.  Since this data maintained by the US
>Government the data should be public domain.  The main entry page for
>the database is here:  ...

I've doing some broadcast stations manually as I've come across them when 
surveying, to try and get a good idea how to model the license and other 
information, at the same time thinking about a unified schema for other 
communications services. Here's an example:

http://www.openstreetmap.org/?lat=34.094622&lon=-117.614315&zoom=18&layers=B000FTF


--
Alan Mintz 


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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Richard Welty]

On 2/8/10 2:34 PM, Mike N. wrote:
>
>> Third, I consider a reference containing just the number to be
>> incomplete.  IMHO, the ref tag should contain the complete designation
>> of a piece of highway.  This also makes it easier to search for this.
>>  
>To search, just search for both the network and route tags.  It's just as
> though the information was placed in separate database columns.
>
quite. the format for ref in relations is very clear, for example

network=US:I
ref=95

take the tail of the network (after the last :) and the ref, and you 
have your
designation for shield purposes: "I 95" this is a pretty trivial 
construction
process, and it works for everyplace the network tag is correctly set. 
if the
shield info is available, then fetch the shield using the appropriate method
(probably with a generic shield available based on the network as a 
fallback)
and superimpose the ref.

where it gets interesting is with certain named parkways (common around
NYC). i've been setting the ref tags for those to their initials (e.g., 
TSP for
Taconic State Parkway). a typical shield for such a parkway looks like this:

http://en.wikipedia.org/wiki/File:Taconic_State_Pkwy_Shield.svg

i'm inclined to think the initials are an adequate solution. but others 
might
disagree...

richard


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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations

[Jeffrey Ollie]

On Mon, Feb 8, 2010 at 1:13 PM, Matthias Julius  wrote:
> Jeffrey Ollie  writes:
>
>> What's more annoying is that he is changing the names/refs.   From
>> what I understand the ref is supposed to be only the
>> interstate/highway number (e.g. "90" or "80") and not "I 90 (MN)".
>
> And I don't like this at all.  First, this seems to be different than
> how this is handled in many other places in the world.  From what I
> have seen in Europe there is always the complete designation how it is
> found on highway shields used in the ref tag.

I don't know if you have travelled much in the US and I've never been
to Europe, but US road signs are pretty minimal:

http://en.wikipedia.org/wiki/File:I-80.svg
http://en.wikipedia.org/wiki/File:US_69.svg
http://en.wikipedia.org/wiki/File:Iowa_3.svg

The color and shape of the sign is used to distinguish different types
of routes.

> Second, separating out the highway system requires the data consuming
> application to know how to piece things back together.  Otherwise, a
> shield on a map for example with just a "25" in it is pretty limited in
> use.

Again, the color and shape of the shield is used to distinguish different routes

> Third, I consider a reference containing just the number to be
> incomplete.  IMHO, the ref tag should contain the complete designation
> of a piece of highway.  This also makes it easier to search for this.

That's why I set the name tag on the relation to something a little
more descriptive.

Obviously, this scheme works only in the US, which is why the
"network" tag is used to distinguish US routes from those in other
countries.

-- 
Jeff Ollie

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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations

[Mike N.]

> Second, separating out the highway system requires the data consuming
> application to know how to piece things back together.  Otherwise, a
> shield on a map for example with just a "25" in it is pretty limited in
> use.

  After / if a generalized shield solution is in place, a 25 placed on an 
'Interstate' shield is quite descriptive.   It avoids the need for the 
renderer or consumer to parse out the number.

> Third, I consider a reference containing just the number to be
> incomplete.  IMHO, the ref tag should contain the complete designation
> of a piece of highway.  This also makes it easier to search for this.

  To search, just search for both the network and route tags.  It's just as 
though the information was placed in separate database columns.

 


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

Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations

[Matthias Julius]

Jeffrey Ollie  writes:

> What's more annoying is that he is changing the names/refs.   From
> what I understand the ref is supposed to be only the
> interstate/highway number (e.g. "90" or "80") and not "I 90 (MN)".

And I don't like this at all.  First, this seems to be different than
how this is handled in many other places in the world.  From what I
have seen in Europe there is always the complete designation how it is
found on highway shields used in the ref tag.

Second, separating out the highway system requires the data consuming
application to know how to piece things back together.  Otherwise, a
shield on a map for example with just a "25" in it is pretty limited in
use.

Third, I consider a reference containing just the number to be
incomplete.  IMHO, the ref tag should contain the complete designation
of a piece of highway.  This also makes it easier to search for this.

Matthias

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

Re: [Talk-us] US highway tagging and relations

[Matthias Julius]

Jeff Barlow  writes:

> Shows how? This is not obvious to me. Are there examples
> somewhere? If they are not connected then are we supposed to move
> them around till they are? If so how does one guess where they
> are supposed to go?

There is a sort button in the relation editor (the fifth from the top
on the left hand side).  With that JOSM tries to sort the relation
members so that the end of one way in the list connects to one end of
the next way.

Matthias

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

Re: [Talk-us] FCC Antenna Structure Import

[Mike Thompson]

Jeff,

One more thing.  You may want to be careful about eliminating
duplicates.  For example, if you have a microwave tower that
communicates with two other sites, it will be in the FCC data twice at
the same location.  To me that is not a "duplicate" as each record
will contain different information about the remote site it
communicates with.

Mike

On Mon, Feb 8, 2010 at 11:14 AM, Mike Thompson  wrote:
> Jeff,
>
> I have worked with this data before (not for OSM).  The data is in the
> public domain.  Your approach sounds sensible to me.  Many of the
> locations are grossly wrong.  So it is important to do manual cleanup.
>  By the way, license holders are liable for a fine if the coordinates
> in this database are wrong.  The FCC might be very interested in OSMs
> feedback!
>
> Mike
>
> On Mon, Feb 8, 2010 at 10:47 AM, Jeffrey Ollie  wrote:
>> The FCC maintains a database of antenna structures which includes an
>> approximate geographic location.  Since this data maintained by the US
>> Government the data should be public domain.  The main entry page for
>> the database is here: 
>>
>> I'd like to do some semi-automatic imports of this data in my
>> locality. I don't think I'll do mass automated imports for large areas
>> because many antennas have already been mapped and the coordinates
>> provided in the FCC database are only approximate.  What I plan on
>> doing is generating a OSM file, loading it into JOSM, and then
>> manually de-duplicate and adjust the coordinates based upon aerial
>> imagery.
>>
>> Here's what a sample looks like (at least in the current iteration of
>> the code).  I'm still looking over the data to see if there are any
>> other useful fields that can be pulled out of the FCC database.
>>
>>  
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>    > v="http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp?regKey=2645662"/>
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>  
>>
>> The "fcc:registration_number" should be posted on a sign near the
>> tower, which should make it easier to match up ground observations
>> with what is in the database.  The "fcc:unique_system_identifier" is a
>> key into the FCC's database.  My script uses the services of
>>  to parse the addresses in the database.  If
>> geocoder.us can't parse the address I just stick the unparsed address
>> in a "addr:full" tag.
>>
>> I'd love to know if I'm being stupid or if there are any improvements
>> people have.  Once the script seems fairly stable I'll upload it
>> somewhere and post the location.
>>
>> --
>> Jeff Ollie
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>

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

Re: [Talk-us] FCC Antenna Structure Import

[jamesmikedup...@googlemail.com]

I have imported the next gen radio stations before.
http://wiki.openstreetmap.org/wiki/Potential_Datasources#Next_Generation_Radar_.28NEXRAD.29_Locations

http://www.openstreetmap.org/browse/changeset/3350339


On 2/8/10, Mike Thompson  wrote:
> Jeff,
>
> I have worked with this data before (not for OSM).  The data is in the
> public domain.  Your approach sounds sensible to me.  Many of the
> locations are grossly wrong.  So it is important to do manual cleanup.
>  By the way, license holders are liable for a fine if the coordinates
> in this database are wrong.  The FCC might be very interested in OSMs
> feedback!
>
> Mike
>
> On Mon, Feb 8, 2010 at 10:47 AM, Jeffrey Ollie  wrote:
>> The FCC maintains a database of antenna structures which includes an
>> approximate geographic location.  Since this data maintained by the US
>> Government the data should be public domain.  The main entry page for
>> the database is here: 
>>
>> I'd like to do some semi-automatic imports of this data in my
>> locality. I don't think I'll do mass automated imports for large areas
>> because many antennas have already been mapped and the coordinates
>> provided in the FCC database are only approximate.  What I plan on
>> doing is generating a OSM file, loading it into JOSM, and then
>> manually de-duplicate and adjust the coordinates based upon aerial
>> imagery.
>>
>> Here's what a sample looks like (at least in the current iteration of
>> the code).  I'm still looking over the data to see if there are any
>> other useful fields that can be pulled out of the FCC database.
>>
>>  > id="-5">
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>    > v="http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp?regKey=2645662"/>
>>    
>>    
>>    
>>    
>>    
>>    
>>    
>>  
>>
>> The "fcc:registration_number" should be posted on a sign near the
>> tower, which should make it easier to match up ground observations
>> with what is in the database.  The "fcc:unique_system_identifier" is a
>> key into the FCC's database.  My script uses the services of
>>  to parse the addresses in the database.  If
>> geocoder.us can't parse the address I just stick the unparsed address
>> in a "addr:full" tag.
>>
>> I'd love to know if I'm being stupid or if there are any improvements
>> people have.  Once the script seems fairly stable I'll upload it
>> somewhere and post the location.
>>
>> --
>> Jeff Ollie
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

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

Re: [Talk-us] FCC Antenna Structure Import

[Mike Thompson]

Jeff,

I have worked with this data before (not for OSM).  The data is in the
public domain.  Your approach sounds sensible to me.  Many of the
locations are grossly wrong.  So it is important to do manual cleanup.
 By the way, license holders are liable for a fine if the coordinates
in this database are wrong.  The FCC might be very interested in OSMs
feedback!

Mike

On Mon, Feb 8, 2010 at 10:47 AM, Jeffrey Ollie  wrote:
> The FCC maintains a database of antenna structures which includes an
> approximate geographic location.  Since this data maintained by the US
> Government the data should be public domain.  The main entry page for
> the database is here: 
>
> I'd like to do some semi-automatic imports of this data in my
> locality. I don't think I'll do mass automated imports for large areas
> because many antennas have already been mapped and the coordinates
> provided in the FCC database are only approximate.  What I plan on
> doing is generating a OSM file, loading it into JOSM, and then
> manually de-duplicate and adjust the coordinates based upon aerial
> imagery.
>
> Here's what a sample looks like (at least in the current iteration of
> the code).  I'm still looking over the data to see if there are any
> other useful fields that can be pulled out of the FCC database.
>
>  
>    
>    
>    
>    
>    
>    
>    
>    
>     v="http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp?regKey=2645662"/>
>    
>    
>    
>    
>    
>    
>    
>  
>
> The "fcc:registration_number" should be posted on a sign near the
> tower, which should make it easier to match up ground observations
> with what is in the database.  The "fcc:unique_system_identifier" is a
> key into the FCC's database.  My script uses the services of
>  to parse the addresses in the database.  If
> geocoder.us can't parse the address I just stick the unparsed address
> in a "addr:full" tag.
>
> I'd love to know if I'm being stupid or if there are any improvements
> people have.  Once the script seems fairly stable I'll upload it
> somewhere and post the location.
>
> --
> Jeff Ollie
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

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

[Talk-us] FCC Antenna Structure Import

[Jeffrey Ollie]

The FCC maintains a database of antenna structures which includes an
approximate geographic location.  Since this data maintained by the US
Government the data should be public domain.  The main entry page for
the database is here: 

I'd like to do some semi-automatic imports of this data in my
locality. I don't think I'll do mass automated imports for large areas
because many antennas have already been mapped and the coordinates
provided in the FCC database are only approximate.  What I plan on
doing is generating a OSM file, loading it into JOSM, and then
manually de-duplicate and adjust the coordinates based upon aerial
imagery.

Here's what a sample looks like (at least in the current iteration of
the code).  I'm still looking over the data to see if there are any
other useful fields that can be pulled out of the FCC database.

  








http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp?regKey=2645662"/>







  

The "fcc:registration_number" should be posted on a sign near the
tower, which should make it easier to match up ground observations
with what is in the database.  The "fcc:unique_system_identifier" is a
key into the FCC's database.  My script uses the services of
 to parse the addresses in the database.  If
geocoder.us can't parse the address I just stick the unparsed address
in a "addr:full" tag.

I'd love to know if I'm being stupid or if there are any improvements
people have.  Once the script seems fairly stable I'll upload it
somewhere and post the location.

-- 
Jeff Ollie

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

Re: [Talk-us] US Chapter temporary Board Nomination

[Serge Wroclawski]

This thread seems the place to be...

I accept the nomination to run for the temporary board of the US Chapter of OSM.

I've been active in the OSM community for about ten months and in that
time I helped found a local mapping group (MappingDC), I've been
acting as secretary for the US Chapter, as well as acting as both
organizer and secretary for the US Chapter and the US State of the Map
calls while Kate Chapman is away. I'm active on the Local Chapters
list, and I'm running this (US OSM Chapter) election.

I'm a longtime member of the DC Tech community, including helping
Tux.org incorporate and  serving on the board of a local tech
non-profit in DC. I think my past experience in knowing what has
worked and what doesn't could really be an asset to our budding
organization and would love to be given the opportunity to use that
experience to benefit the OpenStreetMap community.

- Serge

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

Re: [Talk-us] US Chapter temporary Board Nomination

[Kate Chapman]

I'm going to jump on this thread as well.

I accept the nomination to run for the temporary board of the US Chapter of OSM.

I was on the board of the DC Rollergirls when they incorporated as a
non-profit as well obtained tax-exempt status.  I think my experience
going through this process will be helpful to the US Chapter of OSM.
Though I've been missing from the calls the past couple weeks due to
the earthquake in Haiti, previously I was helping organize the US
chapter and figuring out how we could run this election process.

I'm excited about the prospect of an official US chapter so that we
can interact in a more official capacity with governments within the
United States.

Thanks,

Kate Chapman

On Sat, Feb 6, 2010 at 9:01 PM, Ian Dees  wrote:
> I hope you don't mind me attaching to your thread, Richard.
>
> I accept the nomination to run for the temporary board of the US chapter of
> the OSM Foundation.
>
> I believe I would be an excellent temporary board member. I have experience
> working as a member of and leading organizations in college. In addition, I
> worked to promote OSM in the US by acquiring donated servers and rack space
> and have spoken at a local GIS users group.
>
> -Ian
>
> On Sat, Feb 6, 2010 at 8:20 AM, Richard Welty 
> wrote:
>>
>> I accept the nomination to run for the temporary board of the US chapter
>> of
>> the OSM Foundation.
>>
>> I have been a participant in the working group for the US chapter since
>> the regular calls started in November of last year. I am reasonably
>> current
>> in the issues at hand and thus can hit the ground running.
>>
>> I have served in officer and board positions in other not-for-profit
>> organizations currently and in the past and feel that I have a fair grasp
>> of
>> the issues involved in the administration of such organizations. I look
>> forward to continuing to help in the launch of the US Chapter of the OSM
>> Foundation.
>>
>> Richard Welty
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>

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