Re: [Talk-us] Help fight advertising
It seems like encouraging SEO firms to operate within OSM guidelines by providing an easy way to add the OSM appropriate information in bulk (with data validation) in one step would be a good thing. Easier to contact, manage and block or revert as needed. An idea for catching the throwaway accounts could be a maproulette verification for new user edits? Or a delayed captcha e-mail challenge for the 1st edits to stay in OSM? Dale Puch On Fri, Mar 2, 2018 at 12:40 PM, Clifford Snow <cliff...@snowandsnow.us> wrote: > Sorry for the late posting - I've been working on another project for the > past few days. > > Frederik wrote "You will be surprised about the breadth of marketing blurb > that has already crept into OSM." > > Unfortunately no, I'm not surprised. Marketing is a very competitive > world. SEO firms are using every trick in the dictionary to improve their > page ranking. Thanks to the volunteers that maintain our website(s), OSM > goes to great pains to insure that every URL we display on our website is > followed by a nofollow reference tag. And they have been doing this for > years. For those that aren't aware, it's believed that links to your > business from authoritative websites increases brings your website closer > to the top of searches. OSM.org has a really high authority rating. But now > it seems that the nofollow reference tag isn't enough. According to one of > the top SEO firms in the US, believe that search engines now look to see if > they are on Bing, Yahoo, Google, etc. They believe this not because the big > search companies publish this information but from reverse engineering the > factors to contribute to ranking. > > To me that leaves us with a couple of choices. One, we continue to develop > more sophisticated tools to identify and revert the spam or two, we develop > tools to help SEO firms add data to OSM in a manner acceptable to us. Or > maybe some of both. Jason Remillard post has some positive recommendation > on how to do the first. We should listen to him. One recommendation - make > what we do very public. If SEO firms realize that they are wasting money > they may stop. Remember they are very good at figuring out how to > manipulate search engines. If they can do that, they can figure out how to > better mask their edits. > > As for the second suggestion, make it easier for SEO firms to add data, we > could create a policy and process to accept imports from SEO firms. The > other web map sites like Google, Bing, Apple etc. all have a process for > bulk loading data. (And none are the same.) We could do something similar. > A policy and specialized import guidelines would need to be created. > > Creating a bulk loading policy doesn't mean we don't follow Jason's > recommendation for those that don't follow our policy. > > One of my beliefs from looking at SEO spam is that I believe the work is > likely being outsourced. Two many similarities exist that to me suggest > these are coming from a common source. The user name, the changeset > comments, etc. I did ask Margaret Seksinski with Brandity if she could help > us learn who might be behind this spam. I have yet to hear from her. > Unfortunately, it appears Brandify doesn't want to be a part of the > community, just use us for their gains. > > Frederik suggested we contact the user. I've sent numerous message and > have not only not had any response, but have yet to see any change in their > behavior. Frankly it's a waste of my time anymore to attempt to contact > them. > > As much as I hate the spam in the description tag (should rename it > spam=*) it is helpful in attempting to determine the correct tags. After > which, it's no longer useful and can be deleted. > > Finally let's not lump all SEO firms together. The Laua Group is doing a > great job for Hilton Hotels. We should encourage more firms to be good > community members. > > Best, > Clifford > > > > On Thu, Mar 1, 2018 at 3:21 PM, Ian Dees <ian.d...@gmail.com> wrote: > >> Hi Frederik, >> >> I disagree that this is a "fight". Have we attempted to reach out to the >> people running this operation? Have we asked the Operations team to >> correlate IP address for the accounts that are created and used once? Have >> we looked at what email addresses they use when signing up for clues? It >> would be great to have these folks contributing the non-advertising parts >> in a manner consistent with the rest of the community, and perhaps they'd >> be willing to adjust their practices if we are able to ask them. >> >> Also, your characterization of US mappers being more lax about this is a >> little insulting. OpenStreetMappers in the US spend lots of time lo
Re: [Talk-us] FBI using OSM on website... without attribution
My mistake, Leaflet's example map and code on their main page do show
correct attribution to OSM
So back to the FBI https://www.fbi.gov/cve508/technical-support seems to
suggest contacting a community outreach specialist in your local field
office (via a dead link for me).
https://www.fbi.gov/contact-us/field-offices/richmond/community-outreach-1
just lists training...@ic.fbi.gov as a possible contact
Dale Puch
On Fri, Jun 30, 2017 at 5:01 PM, Denis Carriere <carriere.de...@gmail.com>
wrote:
> It's not Leaflet's fault the attribution is incorrect, their website is
> disabling the default attribution and adding a custom one.
>
> *~~*
> *Denis Carriere*
>
> On Fri, Jun 30, 2017 at 3:37 PM, Dale Puch <dale.p...@gmail.com> wrote:
>
>> A better route is to contact http://leafletjs.com/ since they are
>> providing the actual map data thru their script. Also they probably do so
>> for lots of other sites.
>> Leaflet does attribute Openstreetmap at the bottom of their main page
>> page though.
>>
>> Dale Puch
>>
>> On Fri, Jun 30, 2017 at 2:36 PM, David Kewley <david.t.kew...@gmail.com>
>> wrote:
>>
>>> It looks like all the FBI field office sites are essentially part of the
>>> national site, so they're all probably managed centrally. They all credit
>>> Leaflet in the map widget, and use OSM tiles without crediting OSM.
>>>
>>> It's been years since I've noticed webmaster links, like we used to have
>>> in the early days of the Web. Poking around, I couldn't find any technical
>>> feedback links at all on fbi.gov. Ideas for contacting someone who
>>> might be able to help with this issue:
>>>
>>>- Call the national FBI number: (202) 324-3000 from
>>>https://www.fbi.gov/contact-us/fbi-headquarters
>>><https://www.fbi.gov/contact-us/fbi-headquarters>.
>>>- Email one of the Community Outreach addresses available at various
>>>field offices ("Community Outreach" link near the top of each field
>>>office's page). E.g. for the San Francisco office, it's
>>>outreach...@ic.fbi.gov from https://www.fbi.gov/conta
>>>ct-us/field-offices/sanfrancisco/community-outreach-1
>>>
>>> <https://www.fbi.gov/contact-us/field-offices/sanfrancisco/community-outreach-1>.
>>>Some other field offices also have outreach email addresses.
>>>- On their "Businesses" page https://www.fbi.gov/resources/businesses,
>>>they have a link for "Intellectual Property Theft/Piracy" at
>>>https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft
>>><https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft>.
>>>While this issue seems economically tiny compared to the IP theft issues
>>>they tend to spend time on, it might be possible to get someone's help
>>> this
>>>way, since it's their own website. (Although the reporting methods I
>>> found
>>>went to other offices, not obviously directly to the FBI.)
>>>
>>> I won't be following up on these in the foreseeable future, but if
>>> someone else does follow up, please let us all know what happens.
>>>
>>> David
>>>
>>> On Fri, Jun 30, 2017 at 10:40 AM, Joseph R. Justice <jayare...@gmail.com
>>> > wrote:
>>>
>>>> On Thu, Jun 29, 2017 at 4:14 PM, Mike Thompson <miketh...@gmail.com>
>>>> wrote:
>>>>
>>>> https://www.fbi.gov/contact-us/field-offices/denver
>>>>>
>>>>> See map in upper right part of page
>>>>>
>>>>
>>>> Does either the page for the Denver field office, and/or the
>>>> nation-wide field office locator referred to in a separate post in this
>>>> thread, include a "Contact the Webmaster" sort of link? Or even just a
>>>> "Contact Us" link? Those would be a first obvious point of contact, I'd
>>>> think...
>>>>
>>>>
>>>>
>>>> Joseph
>>>>
>>>>
>>>> ___
>>>> Talk-us mailing list
>>>> Talk-us@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>>
>>>>
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FBI using OSM on website... without attribution
A better route is to contact http://leafletjs.com/ since they are providing
the actual map data thru their script. Also they probably do so for lots
of other sites.
Leaflet does attribute Openstreetmap at the bottom of their main page page
though.
Dale Puch
On Fri, Jun 30, 2017 at 2:36 PM, David Kewley <david.t.kew...@gmail.com>
wrote:
> It looks like all the FBI field office sites are essentially part of the
> national site, so they're all probably managed centrally. They all credit
> Leaflet in the map widget, and use OSM tiles without crediting OSM.
>
> It's been years since I've noticed webmaster links, like we used to have
> in the early days of the Web. Poking around, I couldn't find any technical
> feedback links at all on fbi.gov. Ideas for contacting someone who might
> be able to help with this issue:
>
>- Call the national FBI number: (202) 324-3000 from
>https://www.fbi.gov/contact-us/fbi-headquarters
><https://www.fbi.gov/contact-us/fbi-headquarters>.
>- Email one of the Community Outreach addresses available at various
>field offices ("Community Outreach" link near the top of each field
>office's page). E.g. for the San Francisco office, it's
>outreach...@ic.fbi.gov from https://www.fbi.gov/
>contact-us/field-offices/sanfrancisco/community-outreach-1
>
> <https://www.fbi.gov/contact-us/field-offices/sanfrancisco/community-outreach-1>.
>Some other field offices also have outreach email addresses.
>- On their "Businesses" page https://www.fbi.gov/resources/businesses,
>they have a link for "Intellectual Property Theft/Piracy" at
>https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft
><https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft>.
>While this issue seems economically tiny compared to the IP theft issues
>they tend to spend time on, it might be possible to get someone's help this
>way, since it's their own website. (Although the reporting methods I found
>went to other offices, not obviously directly to the FBI.)
>
> I won't be following up on these in the foreseeable future, but if someone
> else does follow up, please let us all know what happens.
>
> David
>
> On Fri, Jun 30, 2017 at 10:40 AM, Joseph R. Justice <jayare...@gmail.com>
> wrote:
>
>> On Thu, Jun 29, 2017 at 4:14 PM, Mike Thompson <miketh...@gmail.com>
>> wrote:
>>
>> https://www.fbi.gov/contact-us/field-offices/denver
>>>
>>> See map in upper right part of page
>>>
>>
>> Does either the page for the Denver field office, and/or the nation-wide
>> field office locator referred to in a separate post in this thread, include
>> a "Contact the Webmaster" sort of link? Or even just a "Contact Us" link?
>> Those would be a first obvious point of contact, I'd think...
>>
>>
>>
>> Joseph
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] "toll" related tags appropriate for park entrances?
The tag seems functionally correct, it is paid access. Fee might apply, but it seems more like it applies to the park itself, not the roads, or you end up creating a very similar but specific use tag just for parks. As for routing, if the distance around is far enough, and the road size/speed high enough then it can become the better route. It is a function of giving enough data for the routing software to make the right choice. The toll cost might be high enough that it would be smart for the routing software to be written to avoid it anyhow. On Wed, Mar 22, 2017 at 10:07 AM, Kevin Broderick <k...@kevinbroderick.com> wrote: > Functio Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Deletion rampage by a certain user
Can the tools filter selected items from a change set when performing undelete? IE. only undelete stuff from Clay? If not is there a reasonable way to export the changeset and manually review then re-upload as new or undeleted items? Sorry not familiar with the details of doing an changeset restore/undelete. Dale Dale Puch On Mon, May 18, 2015 at 7:13 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 05/19/2015 12:51 AM, Clay Smalley wrote: Last winter, I drove around a bunch of neighborhoods with my GPS and manually added them into OSM. I wanted to add a few more neighborhoods today, so I opened up OSM and went to that area, and a significant chunk of my additions were mysteriously deleted. At first glance it really looks as if the user did nothing more than random deletions across the country. I wonder why it hasn't been noticed before. Then again, many of the objects he deleted are ones he had created himself - perhaps he did that with the good intention the clean up after having been told that copying from Google is not allowed. Perhaps your stuff was accidentally deleted with his own? I sent him a message about it, and he hasn't responded. This is pretty frustrating. What can I do about this? We can easily undelete things, however we'd have to make sure we identify the right changesets to undo, else we might re-create things copied from Google! It appears to me that simply undeleting all objects deleted in your list of changesets would have this undesirable effect. Also there's a slight danger of bringing stuff back that was deleted 2 months ago and someone else has meanwhile drawn the missing bit again, which would lead to duplicates. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Second thoughts
US 52 FOLLOWS I 94 to me means they are concurrent, even if Minnesota only has signs for I94 instead of I94/US52 So it is a matter of presentation, not facts. Here in Florida there are places where most signs list only one name, but periodically there will be references to other names sharing the same route. Dale Dale Puch On Mon, Oct 13, 2014 at 9:59 AM, Tom Fistere tbfist...@gmail.com wrote: Hello! My name is Tom Fistere and I go by CountryLoon on OSM. After about a week of editing I thought I should throw out a couple of questions and comments of what I am doing so far... I have started looking at the road typing throughout the state of Minnesota as it gives me an opportunity to study the status of the map statewide. I see areas that are well documented and drawn and then there are areas so neglected that the lines and imagery are needed some immediate help. I invite anyone to check out my editing job on the segment of MN 23 between St Cloud and Foley, MN as it was rebuilt to an expressway in 2013 and let me know how I did. A couple of questions, Minnesota hates concurrent highways. US 52 is concurrent with I 94 from St Paul, MN to Fargo, ND according to AASHTO but MNDoT refuses to sign the routing beyond US 52 FOLLOWS I 94 sign at the interchange in St Paul. A similar thing occurs with US 12 through the Twin Cities to the Wisconsin line. Should the map reflect the concurrency or not? Google chose to do it but since it is unsigned, I lean toward not showing it. Most of my information is coming from county GIS sites and DOT, are there other other sites I should be checking into when looking for information verification? So far my interest is in the road network but I am willing to branch off into recreational trails and such in the future. Thanks! Tom ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
I see the reason for all this work is to make the data un-ambigious. To that end expanding all the contractions. This is needed for text to speech, consistent searches, and probably a few other issues. From the expanded data names can be contracted a lot easier without mistakes. Raw data: northwest 15th drive spoken data: northwest fifteenth drive Map data: NW 15th Dr. I don't think we need to store 2 or 3 copies for 99.9% of the names, but some will break the rules the rest follow and need some kind of don't expand flag or alt name(s) stored because of that. Dale Puch On Mon, Jul 21, 2014 at 9:45 AM, Serge Wroclawski emac...@gmail.com wrote: On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron mikel.ma...@gmail.com wrote: Here in Washington DC, the street names are all suffixed with the quadrant (NW, SE, SW, NE) the road lies in. The official names of the streets kept by the DC city government all use the contraction. Historically, I could find no maps that used the expansion. The city maps may use the same contractions as TIGER, etc. but we know they're contractions, which is distinct from being words, so I don't the city maps as being a reason for changing the way the entire OSM project handles contractions. BTW, for anyone who isn't aware, I lived in DC from 1996-2012, which is both a long time, and also a recent time. I consider myself essentially a local in this matter. For spoken navigation systems, this is probably the easiest situation to identify and handle, without ambiguity. The real issue is trying to standardize the OSM data for data consumers, which text-to-speech systems will benefit from, but they're not the only ones. OSM maps of DC now just look a bit bizarre. The MapBox folks seemed to have figued this out US-wide and re-contract the road names and the directional identifiers. This is a rendering problem- one which I agree with you 100% that it should be fixed, not just for directions but also for road identifiers, because we in the US are used to seeing contractions. Another proposal I've seen which seemed interesting (though not free of problems) is the idea of a new tag that was basically the name of the road exactly as it appears on a road sign. I agree with you 100% that we should strive for a map that looks American for US map users. The MapBox folks seem to have done it, so really this is a problem with osm.org's map. Their map is really British-Euro centric in many ways, and it would really be nice if we had a good, solid alternative, much like osm.fr. Maybe MapBox can share some of their style with us, or if not, we have our work cut out for us, but I'm sure we can do it. So I don't recommend we apply this expansion without consideration of regional variation. Before any expansion scripts are run, in DC or anywhere, the local community needs to be consulted sufficiently. Can you elaborate on this? - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
My 2 cents. I reviewed a script for expanding names a year or two ago (yours I think), and thought it worked very well. I do not recall finding any false positives. If we have over 100,000 new names that it would catch then it sounds like we need to run it on a regular basis. Or are there so many because the script only ran on tiger entries by default? I say retest the script detection and use it regularly for the start/end abbreviations. Expand it to other detection if it can be shown to be reliable. Throw in a semi regular MapRoulette task to look for more complicated or vague abbreviations and the problem can be kept under control. This can also be used to verify advanced scripts reliability by offering a suggested expansion on the harder names. If there is still any concern of incorrect expansion, output logs with old/new names, links to the ways and a link for revert and tag not to expand in the future. MapRoulette should also have a checkbox to block further expanding a name in future checks. Dale Puch On Sat, Jul 19, 2014 at 12:27 PM, Serge Wroclawski emac...@gmail.com wrote: Hi all, After reading about the issues with Scout and problems with name expansion, I decided to do a little thinking on this issue. The short answer is that Scout (as well as other text to speech engines) should not need to be expanding values, ie E - East. The reason for this is that practice is error prone. We can (and largely have) solved this problem through expanding names in the raw values. A couple of years ago, I ran a bot that expanded hundreds of thousands of names in OSM. The bot was very conservative about what it expanded, which was good, but it also meant that we had a lot of names that were left unexpanded- and as we know, if there are enough exceptions, we have to treat those exceptions as the norm. That leads to exactly the kind of problem Scout is experiencing now. From their perspective, if there's a large number of unexpanded names, then they have to do the expansion themselves, so I decided to look at the scope fo the problem. I took an extract of OSM of North America and looked at the last words in road names and looked for words that looked like contractions I found the following words that look like abbreviations: Dr, Rd, St, Ave, Ln, Blvd, Cir, Pl and Hwy. The total number of instance of finding one of those at the end of a road name was 71100. In addition, I found a bunch of directional prefixes that are probably directional abbreviations, NE, NE, SW and SE. There were 29,130 instances of those. And then for N, S, E, W, there were a total of of 13,494 When you look at the total of these values, the number becomes pretty scary- over 100,000 objects, which is just about 10% of all roads. That means that if you're parsing OSM data, 1 in 10 roads you find will have contractions. The numbers get worse when you realize that this analysis only covered the last word in a road name, not any other word in it. I suspect the real number would be much higher. I think we (the US OSM community) should try to make it easier for our data consumers to work with our data by making it more consistent. So here's what I'm thinking, and I'd really like a dialog about this: 1. I think for the first case, for Rd as the last word, we can be reasonably sure that this is a contraction for Road and we can expand it. This won't trigger the Saint problem because ot would only trigger if St was the last word in the name. 2. I think we can do the same thing for NW/NE, etc. Those seem safe to me. 3. We could probably do the same type of expansion of NE, NW, SE, SW if it's the first word in a name. 4. We work on some better ways of detecting these contractions and decide what to do with them in the future (maybe find a way to expand them automatically, maybe use MapRoulette, maybe use notes, etc.) I'm not saying I'm going to do this. I'm not even officially proposing it yet. I'm pointing out a problem and potential solution. My feeling is that if we can drop the number of problems in our dataset by 90% without much effort, then we should do that. I really want to hear people's thoughts on this. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Sidewalks as footpaths
Personally, I like to treat most sidewalks that are close to and basically parallel the same as attached ones. IE. both of Martijn's examples tagged as part of the roadway way. I would save the separate footpath highways for when it isn't a typical sidewalk. Wider exercise paths that are also part of a network. Portions may fall in the normal sidewalk but is part of a greater whole that does not. Large gaps between the road, more than 3 meters or even 5 meters Deviates from the road, in witch case make the path separate for that block/road segment. Example: http://binged.it/1hf8E3K 2 blocks of Upper Park Road along the park side has a normal sidewalk (I'd map part of the road way), but the rest on the park side I would map as independent footpath ways, even the winding parts that are along the road as they are part of the park sidewalk/exercise trail. But adding and maintaining all the individual sidewalks in the residential part separate form the roads seems counter productive. Dale Puch On Wed, Apr 30, 2014 at 3:19 PM, Elliott Plack elliott.pl...@gmail.comwrote: In Baltimore, I've refrained from tracing too many sidewalks, except when the sidewalk is part of one the the signed city paths. I have noticed that routing that uses OSM (like Strava) tends to choke if all the ways are not there, and also if there are overlapping segments without a node. I like the, *if it is separate* philosophy. On Wed, Apr 30, 2014 at 2:27 PM, Kai Krueger kakrue...@gmail.com wrote: Toby Murray-2 wrote Wait, what is the consensus method for tagging sidewalks? I haven't done a lot of them but I know I've added a few as footways myself. I have struggled with how best to map sidewalks in the US as well. In european cities my impression is that sidewalks are generally directly attached as part of the road, and they are typically just another (special) lane. So there you typically don't map the sidewalks as separate. Footways in those settings generally are real footways and thus deserve the prominence the style sheet gives them. But in the US (at least in suburbia), the sidewalks are often much more detached from the road with wide grass strips between them. They also sometimes aren't entirely parallel to the road. So there it makes more sense to map them as separate OSM ways rather than to use a sidewalk key on the main road. However, the separate ways also can have disadvantages for pedestrian routing. As a pedestrian, I would typically just cross a (non busy) road where ever I need to. If the sidewalks and roads are mapped separately, the router can't just tell you to cross the road though, but needs to route you to the next mapped intersection. One also needs to add a number of connection ways between roads and sidewalks which in that form doesn't really exist in reality, making the maps look even more messy. Not sure there is an ideal solution for this and we will likely see both explicit footway mapping and mapping as part of the road. It would still be good to come to somewhat more of a consensus on the topic though. Kai -- View this message in context: http://gis.19327.n5.nabble.com/Sidewalks-as-footpaths-tp5804729p5804760.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Elliott Plack http://about.me/elliottp ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Burning Man old data, publicity opportunity
A bit off topic here, but all the tools for making and running an OSM database are available and opensource. I'm not sure if it is a good or bad idea for OSM but other layers of data could be developed and stored on other servers. That would keep OSM focused, but allow for more esoteric datasets to be layered on top of it. My vision of that is having the tools and rendering pulling data from both datasets, but it could also just use the OSM tile server with the extra dataset rendered on top. Licensing compatibility/compliance would have to be observed if it used any OSM data or overlays vs. a clean dataset. Dale Puch On Wed, Apr 23, 2014 at 1:54 PM, Martijn van Exel mart...@openstreetmap.uswrote: On Wed, Apr 23, 2014 at 11:07 AM, Richard Weait rich...@weait.com wrote: Secondly, OpenStreetMap data is supposed to be current, rather than historical. There is a separate mailing list for those with an interest in OpenStreetMap and historical objects. The two older version of BM map are an exception in OpenStreetMap data, and sometimes lead to confusion on that matter. Richard is correct, but I want to expand a little on the term 'historical'. Data that has been mapped in OSM but deleted since is gone from the map, but still in the database. It is not easy to get it out, but it can be done. There are 'full history planet dumps'[1] that contain every version of every node, way and relation that have ever existed in OSM - including things that are long gone. If Burning Man artifacts were tagged consistently, you could use a tool like osmium / osmjs to extract them. I agree with both Richard and Serge that we should not purposely map things that are not there, are ephemeral in nature, or keep things on the map that are gone in reality. Burning Man, to my mind, represents an edge case - it's a big event, people build stuff, it has a distinct geographical presence even if for a short time. I'd love to see it mapped but also deleted afterwards, as should the old BM sites in OSM. [1] http://planet.openstreetmap.org/planet/full-history/ [2] https://wiki.openstreetmap.org/wiki/Osmium -- Martijn van Exel President, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] importing zip codes
Others probably gave you what you needed, but here is some links for more reading if anyone wants to understand the issue better. http://www.unitedstateszipcodes.org/ Reasonable write up, similar to what has already been said here. http://faq.usps.com/... USPS FAQhttp://faq.usps.com/adaptivedesktop/faq.jsp?ef=USPSFAQsearch=zip%20codesearchProperties=type%3anaturalnaturalAdvance=falsevarset%28source%29=sourceType%3asearch http://en.wikipedia.org/wiki/ZIP_code https://www.census.gov/geo/reference/zctas.html 2010 stopped filling in national parks and water bodies. http://www.zipboundary.com/zipcode_faqs.html commercial zip code boundry source FAQ explaining the shortcomings of census ZCTA's Dale Puch On Mon, Feb 17, 2014 at 2:11 PM, o...@charles.derkarl.org wrote: Hi, I have a shape file from census.gov which contains the boundaries for all zip codes in the US. This data should not need licensing in that it comes from the us federal census. I would also like the community to answer this technical question: Each boundary obviously shares a border with another zip code. Should those shared boundaries have the same way, and then each zip code becomes a relation? Failing any negative replies, I will cook up an implementation and provide some .osm files for review before importing. Charles Boulder Creek, CA, USA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] battlegrid down
Just a big thank you for all the work you put into these tools. They make finding and fixing problems hidden in plain sight a lot easier, and more fun. Dale Dale Puch On Sun, Nov 10, 2013 at 5:43 PM, Martijn van Exel m...@rtijn.org wrote: and we're back up. Sorry for the inconvenience. My total lack of web server configuration skills finally caught up with me. We're good now. Also, MapRoulette is back to connectivity errors (of which, it turns out, we have another fresh 20k to fix...) until we (yes, that's you :) come up with something new. There's a fair amount of good ideas on the wiki as well as on my blog, I just need to pick something that's easy to implement while we continue our quest to get v2 out the door... Meanwhile. Why not head to http://maproulette.org/ and fix a few! Martijn On Fri, Nov 8, 2013 at 7:41 PM, Martijn van Exel m...@rtijn.org wrote: Hey all, The battle grid is currently down for mysterious reasons. I will investigate tomorrow. Sorry for the inconvenience! -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shining example of OSM use, tarnished.
It seems to be functional for me. Is is not loading tiles for you or is it some other issue? What do you mean by broken images? On Thu, Aug 1, 2013 at 3:22 PM, Bryce Nesbitt bry...@obviously.com wrote: Dear US OSM enthusiasts: Out Whitehouse is using OpenStreetMap: http://www.whitehouse.gov/change Uses CloudMade tiles and OpenLayers to display a... broken map... with broken images. I've emailed the whitehouse webmaster without effect. Is anyone aware of how this map came to be placed here, and who we might contact to get it fixed up as a positive example of OSM, rather than a negative one? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shining example of OSM use, tarnished.
It is largely browser dependent. IE shows different broken zoom/pan images, but the photos in the comments are ok. Chrome also shows broken zoom/pan images and the comment photos are not all fully loaded/shown Firefox is not showing any zoom/pan buttons or broken links and the photos show up fine. On Thu, Aug 1, 2013 at 7:21 PM, Ian Dees ian.d...@gmail.com wrote: What's the issue? Other than the zoom/pan icons missing, it looks fine to me: http://i.imgur.com/5ANaNMB.png We've put in some e-mails to people that might know what's going on there to take a look at those 404s. On Thu, Aug 1, 2013 at 2:22 PM, Bryce Nesbitt bry...@obviously.comwrote: Dear US OSM enthusiasts: Out Whitehouse is using OpenStreetMap: http://www.whitehouse.gov/change Uses CloudMade tiles and OpenLayers to display a... broken map... with broken images. I've emailed the whitehouse webmaster without effect. Is anyone aware of how this map came to be placed here, and who we might contact to get it fixed up as a positive example of OSM, rather than a negative one? ___ 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 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] dirty2osm
Before I whine about what this nice free tool can't do... Thank you! :) Now a suggestion for someone that can add the capability to decode cordinates with minutes and seconds IE. Decimal (WGS84) already working : 28.039521, -81.949792 Decimal Minutes (GPS) : N28 2.37126 W81 56.98752 Degrees Minutes Seconds : N 28° 2' 22.2756, W 81° 56' 59.2512 Since it seems to mainly be a Regex match, perhaps this will help https://gist.github.com/moole/3707127#file-gps_coord_regexp On Tue, Jun 25, 2013 at 12:50 AM, Martijn van Exel m...@rtijn.org wrote: Sometimes I get coordinates like this: 37.3443,-110.3246 or like this: http://www.bing.com/maps/?v=2cp=40.750836~-111.854014lvl=16dir=0sty=rwhere=salt%20lake%20cityss=yp.liberty%20park~pg.1~rad.80form=LMLTCC or like this even: param name=Dest type=java.lang.String value=DLL=37.81209,-122.19888/ And I quickly want to look at that area in OSM. So I hacked this together: dirty2osm http://maproulette.org/ll/ It worked well for me today, used it 30 something times with different kinds of input. Success definitely not guaranteed though. Martijn -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Oklahoma disaster mapping
I found these wiki entries that might help. http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags http://wiki.openstreetmap.org/wiki/Disaster-specific_tags I can only suggest to keep in mind the goal of adding the tags for disasters. Short term is probably narrowing the most severely hit areas, and where to find help/support services. Long term to aid in recovery and rebuilding. On Wed, May 22, 2013 at 10:50 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Wed, May 22, 2013 at 7:09 AM, Mikel Maron mikel_ma...@yahoo.com wrote: HOT is engaged, but right now as http://mapmill.hotosm.org/sort/ok/ Very nice, but the text of the instructions refers to Hurricane Sandy. Is there an official announcement that I could re-share on FB or G+ to get some more help? -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] key source:maxspeed
source:maxspeed examples of use seems appropriate and match the wiki links as they currently are. The changes to the wiki seem to cover using this tag is many places in the US where roads are explicitly tagged and the source can only be from survey(sign) or a database/records. The tag examples you gave seem to indicate your only referring to use in the US. That said. What is an example of this tagging causing problems? Well I guess Survey and Implicit are vague, and I would guess those should be sign and the implicit standard respectively. But I still do not see a real issue if this tag is used as the data source so it can be verified/updated. Is this used some other way? On Sat, Mar 23, 2013 at 7:05 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/3/23 Paul Norman penor...@mac.com: It’s worth noting that source:maxspeed=sign is the most common value. I looked at the last-touched authors for a couple of the country:region values and for sign and survey and it was my impression that sign and survey had a wider distribution of users using them. yes, fortunately. The problem I see is not with sign (proposed tag for explicit/sign-posted maxspeeds since the beginning of source:maxspeed) but with FDOT␣Maximum␣Speed␣Limits, massgis and survey, which don't permit to distinguish an explicit from an implicit speed limit. Less fortunate is the value implicit as it doesn't convey information about the context (inside a closed settlement vs. outside, which has implications on the maxspeed value at least in Europe), but at least it indicates the absence of an explicit sign. cheers, Martin ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] new mapper tutorial explaining overlapping Ways?
Hmm... this cover at least part of what you want? http://www.youtube.com/watch?v=5rnBHhD3HUs This is probably too basic http://wiki.openstreetmap.org/wiki/Potlatch_2/Primer Else try http://wiki.openstreetmap.org/wiki/Video_tutorials also some of the youtube videos http://www.youtube.com/watch?v=P8qKaL9IGjk On Sun, Feb 24, 2013 at 1:51 PM, Peter Dobratz pe...@dobratz.us wrote: I'm trying to help along a newer local mapper, and I'm looking for any good tutorials or references to help show how to create Ways without overlapping/self-intersecting. http://www.openstreetmap.org/browse/way/206875817 These are the kind of things that MapRoulette picks up and other users fix, but it would be helpful to not create them in the first place. Maybe it's just as simple as oh yeah, you have to double-click to end a Way in P2, not just retrace back to the beginning point. Peter ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible coping from Google Maps
I see it shows up on google mapmaker, but not google maps except at high zoom as under construction. Is this possibly entered both places by the same person? Regardless it should still be looked into. On Wed, Feb 20, 2013 at 11:05 PM, Clay Smalley claysmal...@gmail.comwrote: If I weren't confined to my phone right now, I'd check it myself, but are there any GPS tracks along the new interchange? On Feb 20, 2013 9:58 PM, James Mast rickmastfa...@hotmail.com wrote: I just happened to spot a place where there is a possible coping from Google Maps. http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemapmakerlon=-75.5301lat=40.07484zoom=16 While it doesn't look exact on the curves, the places where the ramps start/end/merge seems to be an exact match to Google's. The only reason I'm bringing this up is because of Bing Imagery not even showing the construction, let along the completion, of this new interchange on the PA Turnpike (I-76). This interchange was added in Changeset 14937179. - http://www.openstreetmap.org/browse/changeset/14937179 Anybody else have a comment on this changeset. Also, anybody who has previous experence with the user that did this change be willing to contact him? --James ___ 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 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible coping from Google Maps
Ahh nevermind, I just logged into mapmaker and the only user edits there were POI's On Wed, Feb 20, 2013 at 11:37 PM, Dale Puch dale.p...@gmail.com wrote: I see it shows up on google mapmaker, but not google maps except at high zoom as under construction. Is this possibly entered both places by the same person? Regardless it should still be looked into. On Wed, Feb 20, 2013 at 11:05 PM, Clay Smalley claysmal...@gmail.comwrote: If I weren't confined to my phone right now, I'd check it myself, but are there any GPS tracks along the new interchange? On Feb 20, 2013 9:58 PM, James Mast rickmastfa...@hotmail.com wrote: I just happened to spot a place where there is a possible coping from Google Maps. http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemapmakerlon=-75.5301lat=40.07484zoom=16 While it doesn't look exact on the curves, the places where the ramps start/end/merge seems to be an exact match to Google's. The only reason I'm bringing this up is because of Bing Imagery not even showing the construction, let along the completion, of this new interchange on the PA Turnpike (I-76). This interchange was added in Changeset 14937179. - http://www.openstreetmap.org/browse/changeset/14937179 Anybody else have a comment on this changeset. Also, anybody who has previous experence with the user that did this change be willing to contact him? --James ___ 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 -- Dale Puch -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Turn restriction dispute
For the sake of the strength of the project, for the sake of due process, and for the sake of being able to defend any sort of ban or other action, NE2 must have his day in court. He (and those that may defend him) must be able to speak their minds. On the other hand, those the present situation isn't fair to those of us with grievances. The present situation also is, in total, harmful to the project. Agreed. NE2 may need to be banned, or may be valuable to OSM It should not be decided here, but by a formal procedure. My insight in this from past discussions and interaction is that NE2 has to be beaten over the head with incontrovertible evidence before he is willing to back down. The problem is he isn't offering similar evidence to begin with, and refuses to give other users views similar weight to his own. Regarding the restriction in question. As mentioned it would be illegal based on not using the innermost lane, and crossing a solid traffic line. Note that the on-ramp turn lane is the only one with a solid line from where traffic has to stop. On Sun, Feb 10, 2013 at 3:51 PM, Bill R. WASHBURN dygitulju...@gmail.comwrote: At the risk of sounding like I'm defending NE2, one of Ian's points is that NE2 is banned from the list and that discussing this, here, does not allow ALL of the parties in the case to be involved in the discussion. One of the things that we need is a formal and transparent grievance process to correct poor behavior (and to build cases for banishment, when appropriate). In this case, it seems likely to me that the remediation process would have been resisted and the mediators, themselves, would have had their own case(s). For the sake of the strength of the project, for the sake of due process, and for the sake of being able to defend any sort of ban or other action, NE2 must have his day in court. He (and those that may defend him) must be able to speak their minds. On the other hand, those the present situation isn't fair to those of us with grievances. The present situation also is, in total, harmful to the project. Add a side note, I actually do think that the idea of putting changeset approval processes in on new accounts and as a remediation measure in cases like NE2's is a fantastic idea. This would give the community an opportunity to prevent newbie mistakes from making it to the published map, correcting their newbie edit errors for a few edits until it's clear that they get the swing of things, and for sending rogue editors back to get-along-with-the-community school. Bill, aka dygituljunky On Feb 10, 2013 1:57 PM, Paul Johnson ba...@ursamundi.org wrote: On Sun, Feb 10, 2013 at 11:27 AM, Ian Dees ian.d...@gmail.com wrote: If you feel there's a problem with a particular mapper please contact the mapper and the Data Working Group to help mediate the discussion so that it doesn't run rampant and one-sided on the mailing list. Could we get the DWG in on this thread? Enough members of this project are involved in this issue that having this discussion in public where all parties concerned can by a part of the discussion, or at least see the thought process on the DWG's part, that it would be a disservice to hide this in an ivory tower. ___ 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 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Happy New Year from MapRoulette!
Regarding the layer/bridge/tunnel, if you chose this one. Can you add those tags if present to the maproulette info page, maybe name and type as well. Perhaps with different color coded highlights for the two crossing ways. The idea being to be able to see what is wrong at a glance before loading the area to edit. As some of this is not visual, this would also give the roulette user a chance to see if the problem was fixed or a false positive before opening in the editor. On Thu, Jan 10, 2013 at 8:50 PM, dies38...@mypacks.net wrote: Likewise for highways crossing waterways; there are plenty of places where there is neither a bridge nor tunnel where the two intersect. More subtle would be also looking for layer problems where two ways cross and there is a bridge or tunnel, but there are no layer tags. --ceyockey -Original Message- From: James Mast ** Sent: Jan 10, 2013 8:16 PM To: talk-us@openstreetmap.org Cc: m...@rtijn.org Subject: Re: [Talk-us] Happy New Year from MapRoulette! ** ** ** ** Martijn, I have an idea for a new MapRoulette project and want your opinion on the idea. How about highways that intersect motorways (w/ or without a point there)? (snipped content) -James ** ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER expansion bot
I haven't gotten the chance to fully review the new code, so I'm partly going off what the older code did. In this case the original tiger data was changed from: name = Wentworth Ave name_1 = Wentworth Rd to: name = Wentworth Road name_1 = Wentworth Rd Because tiger:name_type: no longer matches what is in name: that will not be changed However tiger:name_type_1: and name_1: do match so the bot would expand name_1: to Wentworth Road Dale On Tue, Nov 27, 2012 at 5:00 PM, Serge Wroclawski emac...@gmail.com wrote: On Tue, Nov 27, 2012 at 4:01 PM, Phil! Gold phi...@pobox.com wrote: How would your bot handle this way? http://www.openstreetmap.org/browse/way/5321758 Phil, The script is available on github (https://github.com/emacsen/tiger-expansion) and I encourage folks to experiment with it to see what it would do, as well as directly editing the source. If you have any problems getting it working, please email me directly or ping me on IRC. - Serge ___ 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] MapRoulette - Connectivity - TIGER tiles
There is often problems with them not loading for me. Usually just random tiles, but on a few occasions I just got nothing for a day or so. Dale On Fri, Nov 2, 2012 at 11:16 PM, Clifford Snow cliff...@snowandsnow.uswrote: Martin thanks for giving us the maproulette for connectivity. It's fun when you have some time to kill or would rather NOT be doing _ (just fill in the blank) Most of the problems are just users forgetting to make a connection, but some times there are other problems that would be easy to fix if I could see the tiger data. But I'm having trouble getting the tiger tiles to load in either Potlatch or JOSM. I'm following the suggested format but I get nothing. JOSM shows http response code 502. I'm using the instructions at http://wiki.openstreetmap.org/wiki/TIGER_2011. Is anyone else having this problem. Thanks, Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
whining. That's what the difficult accounts have effectively said. I think that we can do better than that. I won't suggest that every complaint DWG receives deserves equal weight after consideration of the matter. And I won't suggest that some accounts are always wrong while other accounts are always right. But this is a giant flashing warning light. With a klaxon. [1] We = We as a community ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] which boundaries are these?
You may want http://www2.census.gov/geo/tiger/TIGER2012/PLACE/ For a more direct download. All the other tiger downloads are available by browsing from there. Dale On Thu, Oct 25, 2012 at 3:57 PM, Martijn van Exel m...@rtijn.org wrote: Would those be the same ones you download here http://www.census.gov/geo/www/tiger/tgrshp2010/2010DP1.html (under Places, County Subdivisions and Related Areas)? That link is a geodatabase, but already has population etc so would be useful for ghost town ranking. Martijn On Thu, Oct 25, 2012 at 1:49 PM, Michal Migurski m...@teczno.com wrote: On Oct 25, 2012, at 12:30 PM, Martijn van Exel wrote: Hi all, I want to do a more thorough look into TIGER ghost towns and am thinking about a town-by-town analysis. For that I need proper 'town' boundaries. I like the ones you get when you search for a place on Google Maps: https://maps.google.com/maps?q=princeton,+nj https://maps.google.com/maps?q=nederland,+co What are these boundaries? I am guessing it is some kind of Census division? It's likely to be a Census place, non-continuous areas that can cross other boundaries are intended to represent logical towns and cities. http://www2.census.gov/geo/tiger/TIGER2012/PLACE/ -mike. michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Scrubbing route relations (attn: Richard Welty, etc.)
That is my understanding as well based on previous discussions. For For US Business route 80: network = US:US:Business ref = 80 On Wed, Oct 24, 2012 at 2:13 PM, Alexander Jones happy5...@gmail.comwrote: Using your example, the network tag should say US:US:Business Alexander Michal Migurski wrote: On Oct 23, 2012, at 1:54 PM, Michal Migurski wrote: On Oct 21, 2012, at 8:54 PM, Michal Migurski wrote: I feel like this scrubbing process has revealed so much about the intricacies of different road networks that I'm going to take a slightly different approach, and focus my work on just the ref and modifier tags. I can standardize the US:US and US:I networks along with US:CA where I live, but I should hold off on attempting to overfit other states' network tags. Here's the newest: http://mike.teczno.com/img/OSM-Extracted-Routes-changes-2.csv.zip There are 5,828 changes now. I have left the network tags alone, generally. Most changes are focused on the ref and modifier tags. I'm looking for advice feedback. I applied these changes to OSM last night, in a series of five changesets: http://www.openstreetmap.org/browse/changeset/13611326 http://www.openstreetmap.org/browse/changeset/13612265 http://www.openstreetmap.org/browse/changeset/13612825 http://www.openstreetmap.org/browse/changeset/13612736 http://www.openstreetmap.org/browse/changeset/13613023 Offlist, I've been talking to NE2 about the edits, and he pointed out this morning that they negatively affect shield rendering on Aperiodic: http://elrond.aperiodic.net/shields/?zoom=15lat=38.7166lon=-77.79472layers=B Whereas formerly relations with network=US:US and the modifier in the ref failed somewhat gracefully if a bit pigheadedly (by not displaying shields at all), they now show up incorrectly as mainline routes. - NE2 NE2 asked me to revert the changes, because he's unhappy with me moving the route variant information from the ref tags to the modifier tags, e.g. turning ref=80 Business into ref=80 modifier=Business. According to the supported tagging guidelines on Aperiodic, my interpretation should be correct: The value of the ref tag on the relation must contain just the route number, without any network information. http://elrond.aperiodic.net/shields/supported.html I'm looking for guidance on this changeset, with the intent of making route relation information in the US internally consistent. I can simply revert it, but I wasn't happy with the state of relation tags before and I'll continue to look for ways to make them consistent nationally. I can apply a new changeset that moves or duplicates the variant information in the modifier tags to the ref tags, but this feels incorrect. I can apply an alternative changeset that moves or duplicates the variant information to the *network* tags (another recommendation from the Aperiodic tagging guideline), but previous conversations about this change led me to believe that messing with the network tags too much would be a Bad Idea. For those of you with an interest in the route relations, what do you think is the correct next move here? NE2, I've been talking to you offlist but I hope you jump in here. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] SOTM-US geocoding/share-alike discussion
Perhaps some real world examples would help more people with understanding this. What are some clear acceptable uses, unaccepted and what is still grey areas. Perhaps there should be two answers for the grey area examples, legally, and OSM intent. Wasn't there something like this in the WIKI for the old SA lisense? Dale On Sun, Oct 21, 2012 at 4:58 AM, Frederik Ramm frede...@remote.org wrote: Hi, on talk-us there was a mention of Carl Frantzen's recent three-part article with SOTM-US coverage, http://idealab.** talkingpointsmemo.com/2012/10/**openstreetmap-part-1-new-** cartographers.phphttp://idealab.talkingpointsmemo.com/2012/10/openstreetmap-part-1-new-cartographers.php , and his mention of OSM moving away from his open-source roots. Apparently, this refers to some unfortunate statements at SOTM-US about share-alike being bad for business or something, and Frantzen mentions that a couple of businesses have set up an informal group to discuss which bits of our license they don't understand or want clarification on. As far as I know, nobody who knows anything about OSM seriously suggested that we move away from open source, it was just a phrase unfortunately reported. I am still rather surprised to hear about this as a side note of SOTM-US coverage instead of here on this list where license discussions should be at home. I would urge anyone who is unclear about anything with ODbL and/or who believes that any community norms we have must be refined, to discuss that here on this mailing list - whether it's for business or personal use. Looking through past discussions in the archives of minutes of our Licensing Working Group, it seems clear to me that OSM data under ODbL is unlikely to ever be available for no strings attached geocoding; we won't ask for your customer database just because you geocode with OSM, but you will have to adhere to some rules nonetheless. LWG has never actually made a decision on geocoding, and all mentions in their minutes carry big disclaimers (This is a summary of our discussion and should NOT be construed as a formal statement of position). Under that disclaimer, the 20120515 minutes contain the following: To be able to claim that the remainder of the record, (often proprietary business information or personal information such as a patient record) is not virally touched by geocoding against OSM ODbL data needs a distinction to be demonstrated. This distinction needs to be a clear and logical general rule or principle. It also needs to be acceptable to the OSM community. At the moment, we feel this does not exist. In the same notes there's a discussion of a like with like principle which means that Whatever is used in the (reverse)geocoding look-up is virally touched, but nothing else. The 20120522 meeting notes contain a link to a concept paper https://docs.google.com/**document/pub?id=**1Ag81OlT1TtnhYwVE-bBtL018SNoU_ **V-anG4wLdwMT4chttps://docs.google.com/document/pub?id=1Ag81OlT1TtnhYwVE-bBtL018SNoU_V-anG4wLdwMT4c and explicitly say: To improve it, and test the rationality of the ideas expressed, we need and welcome real-world cases of geocoding and reverse-geocoding. So I guess anyone who wants to use OSM in a geocoding scenario should read that and submit their opinion, here or to LWG. Personally, I've gone on record as an advocate of a non-share-alike (PD) license for OSM but the project as a whole has decided to have a share-alike license and I accept that; I don't think that geocode as much as you want without sharing any data is possible with the ODbL data set. 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-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Burlington, Vermont road classification
Bottom line is it is subjective. Be friendly, make a compromise and have fun mapping. This is something that has shown up a few times that I recall. What I remember from that is primary rely on ground truth but it can be adjusted for map consistency and other extenuating factors. Unfortunately that comes under the judgment of the mappers. Examples: I remember there are Interstates that are actually unpaved in places, but tagged like all the rest of the interstates with perhaps surface=unpaved ect. I think Alaska might be good examples of this but haven't checked into it myself. Another is where the road conditions change for a mile or two before reverting back. Especially if this happens several times in a row it is usually desirable to keep one classification instead of going back and forth. Relative conditions of the area also come into play. It isn't always a question of the road at that specific point meeting a set of requirements. Specifically for your example of US 7 and route 2. Both seem to connect the center of burlington to other major roads and populations centers, not just a local road. My answer that isn't an answer :p Dale On Thu, Oct 18, 2012 at 4:48 PM, Andrew Guertin andrew.guer...@uvm.eduwrote: Hi, There are two active mappers in the Burlington, Vermont area, and we disagree about how the roads should be classified, so we're looking for more opinions. The crux of the problem is the answer to the question: Which is more important, outside/official classifications, or physical characteristics? The tagging pages on the wiki don't really provide clarity on this matter. For example, from [1], Almost all other U.S. Highways get highway=primary. A primary highway generally provides the best route (excluding motorways) connecting adjacent cities or communities Even where U.S. Highways connect only smaller communities, they still merit highway=primary but Primary highways generally lack stop signs; however, stop signs may control major intersections in rural areas with low traffic volumes and occur rarely elsewhere. The most notable example of this is North Willard Street[2]. It is part of US Route 7, but as can be seen with Bing Imagery, it is narrow, made narrower by street parking on both sides, and is controlled by stop signs. Similarly, Main Street is part of US Route 2, but has many lights, and does not even satisfy the near the highest speed generally allowed on surface streets note about secondary streets. Of note, there is in fact no path to get from US 7 south of Burlington to US 7 north of Burlington without stopping at at least one stop sign, except for the interstate. Should this imply that there just aren't any major roads here? We're especially interested in input from nearby states--the rest of New England and northern New York, but of course anyone with an opinion please chime in! Thanks, --Andrew [1] http://wiki.openstreetmap.org/wiki/United_States_roads_tagging [2] http://www.openstreetmap.org/?lat=44.48388lon=-73.20368zoom=16layers=M ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?
For setting up the runs, is it all SQL queries or are there other items involved? Perhaps start a wiki page for useful queries to identify problems (for this or other projects), or even just collaboration on plain text criteria ideas for future runs and build what is needed from there. Dale On Mon, Oct 1, 2012 at 1:52 AM, Martijn van Exel m...@rtijn.org wrote: Also a good one. I will make a list of all the suggestions some time this week. There's some low hanging fruit here, and some more complex ideas. I don't know when I will have time to implement the next level, I hope to have something up before Portland. Any help is appreciated! Martijn On Sun, Sep 30, 2012 at 11:46 PM, Alexander Jones happy5...@gmail.com wrote: Alan Millar wrote: Another suggestion: motorways and trunks without lanes=number tags - Alan I'd help out with that. Alexander ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?
Well as a start is I put a section into the QA tools page http://wiki.openstreetmap.org/wiki/Quality_assurance#Remap-a-Tron Several projects there that ideas/code/SQL might be borrowed from. Well your obviously familiar with this :) did the issues found by this query all get resolved? http://oegeo.wordpress.com/2012/04/07/detecting-highway-trouble-in-openstreetmap/ Also some SQL from a bot http://wiki.openstreetmap.org/wiki/OSM_Fixer that might be of use in building other queries. Dale On Mon, Oct 1, 2012 at 4:04 PM, Martijn van Exel m...@rtijn.org wrote: The setup involves designing the SQL queries and the initial database, and tweaking the front end for different types of problems. Up until now, we have been able to get away with just displaying the non-remapped way as a vector element on the leaflet map, but for example forfolding ways that may not be enough, as the folds may be really tiny and not visible without also displaying the offending piece of the way in a kind of magnifying glass (or in the popup balloon). That would mean significant front-end tweaking as well as partial re-engineering of the webservices that transmit the geojson. (these are really really simple things[1] so that should not be hard to do for someone with a little python / json experience). For the connectivity errors, which are as high on my list as anything to fix, we'd need to transmit both ways involved and find a way to display the issue effectively. Maybe just the two ways in different colors. Nice extra would be if the popup would say 'hey, there are x more connectivity errors within a mile, do you just want to go ahead and edit all of them?' A wiki page is an excellent idea, who has time to set that up? [1] https://github.com/mvexel/remapatron/blob/master/service/get.py On Mon, Oct 1, 2012 at 1:59 AM, Dale Puch dale.p...@gmail.com wrote: For setting up the runs, is it all SQL queries or are there other items involved? Perhaps start a wiki page for useful queries to identify problems (for this or other projects), or even just collaboration on plain text criteria ideas for future runs and build what is needed from there. Dale On Mon, Oct 1, 2012 at 1:52 AM, Martijn van Exel m...@rtijn.org wrote: Also a good one. I will make a list of all the suggestions some time this week. There's some low hanging fruit here, and some more complex ideas. I don't know when I will have time to implement the next level, I hope to have something up before Portland. Any help is appreciated! Martijn On Sun, Sep 30, 2012 at 11:46 PM, Alexander Jones happy5...@gmail.com wrote: Alan Millar wrote: Another suggestion: motorways and trunks without lanes=number tags - Alan I'd help out with that. Alexander ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch -- martijn van exel http://oegeo.wordpress.com -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?
Sounds like the easiest one to start with. Another idea is to go thru the maplint, and other bugs already tagged for armchair fixable items. Some of those will require a different approach, like picking a location that can be physically visited. Printing an list/map and then returning to those items for marking complete after physically visiting them. Dale On Fri, Sep 28, 2012 at 12:43 PM, the Old Topo Depot oldto...@novacell.comwrote: Way connectivity fixes, prioritized by class of way and size of metro area containing them. Largest metro areas, based on population, and highest class ways get higher priority. Simple query; simple fixes. Best, On Fri, Sep 28, 2012 at 8:49 AM, Paul Norman penor...@mac.com wrote: From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Friday, September 28, 2012 8:29 AM Subject: Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3? Level 4 Tiger unedited roads that are highway residential and have no name. How many of those are there? They would only be candidates if they actually have names. How would we know this? Most of the ones I've seen weren't really residential roads but were agricultural tracks or paper roads. That being said, I'm not sure this is a great use case for remap-a-tron because you can't get the names from imagery. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- John Novak 585-OLD-TOPOS (585-653-8676) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] JOSM zoom limits per server solved (fixes Tiger grey overlay )
Not to get into the coding as I have no idea how it is handled, but better
to not offer a 404 page, but to keep the min/max zoom tile as the reply in
this case.
Ie if asking for zoom 20+ return with zoom 19 instead. More of a redirect
instead of 404 if zoom is out of bounds.
One possibility to slightly abuse the zoom limits... tms[19,19]:http://...
probably fine for lots of stuff as you would probably end up at that level
anyhow.
Could we get just 2 zoom levels? say 16 and 19?
Dale
On Sun, Sep 23, 2012 at 2:21 PM, Ian Dees ian.d...@gmail.com wrote:
The root cause if you will, is that TileStache doesn't support 404ing
instead of grey tiles when a request falls out of the specified bounds. If
someone wants to code that up and submit a pull request, I would much
rather use that.
On Sun, Sep 23, 2012 at 1:18 PM, Alan Millar grunthos...@yahoo.comwrote:
I also found there is a minimum zoom also. Put it in the url as min,max
like
tms[16,19]:http://...
Fixes the grey tiles when I zoom back out.
- Alan
On Sep 23, 2012, at 12:54 AM, Toby Murray toby.mur...@gmail.com wrote:
I knew about the max zoom setting but for some reason never thought about
applying it to the TIGER tiles to fix the grey
Toby
On Sep 21, 2012 1:23 PM, Alan Millar grunthos...@yahoo.com wrote:
Maybe everyone else knows this, but I just discovered it myself so I
thought I would share it.
I've been using Remap-a-tron to fix up US roads. I use both the Bing
imagery and the TIGER 2012 tiles overlaid, and it makes it really
useful.
However, I've been frustrated that I can pretty far in with the Bing
images, but if I go too far, the Tiger (normally transparent) tiles turn
grey and obscure the Bing images. I've been continually turning off and
back on the Tiger layer, which is a bit annoying after a while.
JOSM has an easy limit in the Preferences for the maximum zoom, but it
affects everything. I set it to 19, and then I did not get the grey
boxes from Tiger, but did not get the higher detailed photos from Bing
either.
As it turns out, JOSM does have a max-zoom per tile server feature; it
just is not obvious or clearly documented that I could find.
You can enter it as part of the TMS url like this:
tms[19]:http://{switch:a,b,c}.
tile.openstreetmap.us/tiger2012_roads/{zoom}/{x}/{y}.pnghttp://tile.openstreetmap.us/tiger2012_roads/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
The number 19, right up front, says that the maximum zoom to use for
this layer is 19. This solved the whole thing for me.
I also found that if you go into Josm preferences in expert mode, and
dig and dig and dig into the imagery providers entries, this is labeled
as max-zoom. Too bad it isn't easier to find.
Anyways, hope this helps others too.
- Alan
___
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
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
--
Dale Puch
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron observation
I think people react stronger to here is something specific that is missing, go create it then they do to these things might get messed up or deleted if you don't remake them The more straight forward a task, the better the response. Also the less subjective judgments needed the better. Also always presenting a new problem area on completion encourages continual usage. This process could be reused to simi-manually import data that can be verified via sat or other layers. Or to fix imports of questionable quality in the same manner. Dale On Tue, Sep 11, 2012 at 12:16 PM, Martijn van Exel m...@rtijn.org wrote: Because this is the kind of project where people invest their time and creativity mostly if and when they can spare it, not according to an all-encompassing master plan. This Remap-a-tron is a result of a lucky coincidence of a spark of creativity and a modest amount of time being available to me. We could all have planned ahead better with our perfect hindsight. It is not constructive pointing at an unidentified 'someone' who 'should' have done things differently. No one is accountable but we are all responsible. In the end it really comes down to who has the time and skills to get stuff done. Let me also say that there were decent tools available at the time to identify endangered features. Martijn On Tue, Sep 11, 2012 at 9:34 AM, Charlotte Wolter techl...@techlady.com wrote: Mike, Thanks for this information. I have been worrying about the unamed streets that I have been editing. Again, I have to ask, why wasn't a tool like this included in the original redaction? If someone had planned ahead and given the membership this tool and tools like Remap-a-Tron, the whole process would have been easier. We probably should have done Remap-a-Tron before anything was deleted to find and change work done by nonsigners. This is definitely something to remember for the future. Charlotte At 05:36 AM 9/11/2012, you wrote: Just a note to those participating with the awesome Remap-a-tron tool - please take time to look up or verify the road name from TIGER. http://wiki.openstreetmap.org/wiki/TIGER_2011 Use the URLs in the section Tiles in Potlatch or JOSM.You can also substitute the 2012 for 2011 in the URLs to use the latest TIGER information. If you come across a large deleted/empty subdivision - feel free to let us know on the list; it is easier in those cases for one of us to plug in the whole subdivision from the TIGER data. Post the Permalink from Potlatch to give the location. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] The Remap-A-Tron, Second Wave
Another confirmation that all is well again. Thanks for figuring it out. Dale On Mon, Sep 10, 2012 at 5:46 PM, Martijn van Exel m...@rtijn.org wrote: OK get remapping then :) Glad that it's fixed..Need to get my mind around this Apache stuff or leave those config files well alone. Martijn On Mon, Sep 10, 2012 at 3:44 PM, Alan Millar grunthos...@yahoo.com wrote: Yes, that fixed it. Thanks! - Alan From: Martijn van Exel m...@rtijn.org To: Alan Millar grunthos...@yahoo.com Cc: Talk-us@openstreetmap.org Sent: Monday, September 10, 2012 1:50 PM Subject: Re: [Talk-us] The Remap-A-Tron, Second Wave Mweh. I suck at apache configuration. Try again, please? Martijn On Mon, Sep 10, 2012 at 2:42 PM, Alan Millar grunthos...@yahoo.com wrote: Quite a few hours later, I'm still seeing the 403 errors on those two paths. I've cleared browser cache and reloaded, with no improvment :-( Forbidden You don't have permission to access /remappingservice/count on this server. Apache/2.2.14 (Ubuntu) Server at lima.schaaltreinen.nl Port 80 From: Martijn van Exel m...@rtijn.org To: Dale Puch dale.p...@gmail.com Cc: Charlotte Wolter techl...@techlady.com; Talk-us@openstreetmap.org Sent: Monday, September 10, 2012 6:44 AM Subject: Re: [Talk-us] The Remap-A-Tron, Second Wave What is your browser? Can you inspect the network activity on the page? Are http://lima.schaaltreinen.nl/remappingservice/ and http://lima.schaaltreinen.nl/remappingservice/count called and do they return valid (geo)JSON? Can you try a force-reload of the page? (ctrl-shift-r if you use Firefox) Does anyone else still have trouble? On Sun, Sep 9, 2012 at 11:52 PM, Dale Puch dale.p...@gmail.com wrote: Hmm Still seems stuck on the same location for me. I cleared my cache just to make sure that wasn't it. Dale On Mon, Sep 10, 2012 at 12:44 AM, Martijn van Exel m...@rtijn.org wrote: I repaired it - it was an apache config setting that was a little too strict. How'd that happen? Your guess is as good as mine. Bottom line is the Remap-a-tron works like a charm once more. Martijn On Sun, Sep 9, 2012 at 6:58 PM, Martijn van Exel m...@rtijn.org wrote: yea, something busted, I will look into it tonight... Hang in there folks - and thanks for using! Martijn On Sun, Sep 9, 2012 at 6:50 PM, Dale Puch dale.p...@gmail.com wrote: Not sure if it is just me, but this seems stuck today. All was fine yesterday. I only get one map location and it will not move to another with 'W' A few of the deleted ways have led me to some large missing subdivisions and poor downtown type areas... A bit of OCD kicks in and an hour+ later I'm finally done :p Dale On Sun, Sep 9, 2012 at 11:57 AM, Charlotte Wolter techl...@techlady.com wrote: I told Martijn the toold would be a great way to do Projects of the Month or Projects of the Week. Maybe there would be a way to track who did what, so we can recognize people who did a lot of work. Charlotte At 02:20 PM 9/7/2012, you wrote: A fantastic tool! If it can be expanded to finding other issues even better. Dale On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel m...@rtijn.org wrote: Hi, On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski emac...@gmail.com wrote: A similar query could be used to find overlapping ways which are of the same level and do not share a way. This could help with routing. There are a lot of queries like this which wouldn't be hard to do. - Serge Interestingly I was just discussing overlapping ways with Telenav yesterday. This will be a very useful thing to detect, but as these overlapping ways are not visible on the Mapnik map so the R-a-T may not be so useful for that. Some folks over at Telenav are developing a JOSM plugin that works in a similar way (iterating over error points pseudo-randomly and letting you fix them one by one) and may be better suited to these 'invisible' problems. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content
Re: [Talk-us] The Remap-A-Tron, Second Wave
Not sure if it is just me, but this seems stuck today. All was fine yesterday. I only get one map location and it will not move to another with 'W' A few of the deleted ways have led me to some large missing subdivisions and poor downtown type areas... A bit of OCD kicks in and an hour+ later I'm finally done :p Dale On Sun, Sep 9, 2012 at 11:57 AM, Charlotte Wolter techl...@techlady.comwrote: ****I told Martijn the toold would be a great way to do Projects of the Month or Projects of the Week. Maybe there would be a way to track who did what, so we can recognize people who did a lot of work. Charlotte At 02:20 PM 9/7/2012, you wrote: A fantastic tool! If it can be expanded to finding other issues even better. Dale On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel m...@rtijn.org wrote: Hi, On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski emac...@gmail.com wrote: A similar query could be used to find overlapping ways which are of the same level and do not share a way. This could help with routing. There are a lot of queries like this which wouldn't be hard to do. - Serge Interestingly I was just discussing overlapping ways with Telenav yesterday. This will be a very useful thing to detect, but as these overlapping ways are not visible on the Mapnik map so the R-a-T may not be so useful for that. Some folks over at Telenav are developing a JOSM plugin that works in a similar way (iterating over error points pseudo-randomly and letting you fix them one by one) and may be better suited to these 'invisible' problems. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ** ** Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady *The Four Internet Freedoms* Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] The Remap-A-Tron, Second Wave
Hmm Still seems stuck on the same location for me. I cleared my cache just to make sure that wasn't it. Dale On Mon, Sep 10, 2012 at 12:44 AM, Martijn van Exel m...@rtijn.org wrote: I repaired it - it was an apache config setting that was a little too strict. How'd that happen? Your guess is as good as mine. Bottom line is the Remap-a-tron works like a charm once more. Martijn On Sun, Sep 9, 2012 at 6:58 PM, Martijn van Exel m...@rtijn.org wrote: yea, something busted, I will look into it tonight... Hang in there folks - and thanks for using! Martijn On Sun, Sep 9, 2012 at 6:50 PM, Dale Puch dale.p...@gmail.com wrote: Not sure if it is just me, but this seems stuck today. All was fine yesterday. I only get one map location and it will not move to another with 'W' A few of the deleted ways have led me to some large missing subdivisions and poor downtown type areas... A bit of OCD kicks in and an hour+ later I'm finally done :p Dale On Sun, Sep 9, 2012 at 11:57 AM, Charlotte Wolter techl...@techlady.com wrote: I told Martijn the toold would be a great way to do Projects of the Month or Projects of the Week. Maybe there would be a way to track who did what, so we can recognize people who did a lot of work. Charlotte At 02:20 PM 9/7/2012, you wrote: A fantastic tool! If it can be expanded to finding other issues even better. Dale On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel m...@rtijn.org wrote: Hi, On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski emac...@gmail.com wrote: A similar query could be used to find overlapping ways which are of the same level and do not share a way. This could help with routing. There are a lot of queries like this which wouldn't be hard to do. - Serge Interestingly I was just discussing overlapping ways with Telenav yesterday. This will be a very useful thing to detect, but as these overlapping ways are not visible on the Mapnik map so the R-a-T may not be so useful for that. Some folks over at Telenav are developing a JOSM plugin that works in a similar way (iterating over error points pseudo-randomly and letting you fix them one by one) and may be better suited to these 'invisible' problems. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com -- martijn van exel http://oegeo.wordpress.com -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] The Remap-A-Tron, Second Wave
A fantastic tool! If it can be expanded to finding other issues even better. Dale On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel m...@rtijn.org wrote: Hi, On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski emac...@gmail.com wrote: A similar query could be used to find overlapping ways which are of the same level and do not share a way. This could help with routing. There are a lot of queries like this which wouldn't be hard to do. - Serge Interestingly I was just discussing overlapping ways with Telenav yesterday. This will be a very useful thing to detect, but as these overlapping ways are not visible on the Mapnik map so the R-a-T may not be so useful for that. Some folks over at Telenav are developing a JOSM plugin that works in a similar way (iterating over error points pseudo-randomly and letting you fix them one by one) and may be better suited to these 'invisible' problems. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] how to select overlapping objects in Potlatch 2?
Sidetracking a bit, but is there a way to select overlaping items in JOSM? On Thu, Sep 6, 2012 at 9:59 PM, Toby Murray toby.mur...@gmail.com wrote: On Thu, Sep 6, 2012 at 8:22 PM, Peter Dobratz pe...@dobratz.us wrote: A relatively new user has created a bunch of duplicate Ways around here: http://www.openstreetmap.org/?lat=42.732lon=-71.49769zoom=17layers=M So far I've had good email exchanges with this new user, and I was about to send him a message about this area, but I'm not sure where to begin. Obviously, we don't want a bunch of duplicate objects that represent the same thing with almost the same geometry. Looking at the area in Potlatch 2, I can't figure out a way to select just one of the overlapping objects, so I can't even explain to the new user how to clean it up using his editor of choice. Also, I'm confused as to how this happened in the first place. Has anyone else seen something similar to this before? I can clean it up in JOSM, but I want to get on the same page with the new mapper so that he doesn't keep doing it. You can hold down CTRL and drag a box and anything intersecting that box will be selected. But that won't really help you in this case either... I guess you just have to zoom in really far. Then it becomes obvious that there are two ways. I wonder if he had problems downloading data from the API. It's like he got Conant Road downloaded, maybe when he was panned to the west a little. Then maybe he panned east and was unable to load those residential streets? That would explain how he has his own connected network in the area that is connected to Conant Road but nothing else. I would think it would actually be rather difficult to create a self-contained network that is so close to existing objects. Potlatch would tend to snap things to each other so they would be sharing some nodes. That's my theory. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2011 Data
Yep a great feature! Thanks Ian Only thing better would be a data layer that new stuff could be copied from instead of the image layer to trace. On Tue, Jul 3, 2012 at 8:57 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Jul 3, 2012 at 6:41 PM, Clifford Snow cliff...@snowandsnow.uswrote: I just found out that I can overlay the latest TIGER data (2011) on JOSM and Potlatch. Apparently the feature has been there for a while, but I just ran into it and wanted to make sure everyone else was aware. It is much better than running TIGER data through org2osm and overlaying it in JOSM. With this feature, you get can get the roads and names on top of a Bing image. Makes it easy to add new roads into OSM. You do have to expand the names, for example E Elm St. into East Elm Street. And when two roads connect, there is not clear dividing line between the roads, but usually you can tell. The feature is shown on the wiki at: https://wiki.openstreetmap.org/wiki/TIGER_2011 So, whoever added this feature, thank you very much. This is a feature I set up for the community on the OSM US machine. There are several other tile layers available [0] and I would be more than happy to entertain any other ideas or implementations if you have them. [0] http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers/Imagery ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] proposed automated edit: forested wetlands
I think Frederik just meant not to rush between bringing it to the list attention and making the bulk changes. It's sort of like posting out of the blue: I have this import I was working on for a year, if no one objects I'll upload it today. It is all about giving others the time to look and think it over then respond. That said, your tagging suggestion seems sound as per http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland for those who do not feel like searching for it. Dale On Wed, May 30, 2012 at 7:08 AM, Nathan Edgars II nerou...@gmail.comwrote: On 5/30/2012 6:19 AM, *Frederik* Ramm wrote: There's absolutely no reason to rush. Data that's been sitting in OSM for *years* without even being noticed as a problem I noticed it as a problem about a year ago. __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U.S. inland waterways
http://www.ndc.iwr.usace.army.mil//index.htm looks to be one of the places you should look. I found it thru http://www.usace.army.mil/Missions/CivilWorks/Navigation.aspx in case there is more information there. On Wed, May 16, 2012 at 4:51 AM, Richard Fairhurst rich...@systemed.netwrote: Nathan Edgars II wrote: I'm trying to do something like the European tagging: http://www.itoworld.com/map/24 But there they have some sort of international treaty that defines configurations. (puts day-job hat on) For users of a waterway, the European (CEMT) waterway classes describe, rather than define, the size of the limiting structures. They're information, rather than regulation. In other words, although a class Va waterway has a stated length of 110 metres, that doesn't mean that a river policeman will come and flag you down for taking a 115m boat along the river. It's very possible that the locks are (say) 120m long, and if you can get your boat through them, you're absolutely entitled to do so. This is particularly important at the smaller end of things where locks and bridges may be a zillion and one different sizes. (Here in Britain people routinely build boats to 60ft because there are certain locks that are 58ft 6in long... and if you put the boat in the lock diagonally, you can squeeze that little bit of extra accommodation. There are other locks that have subsided to become 1in too narrow for certain historic craft that would once have used the locks. And so on.) So the ideal is to tag each structure with its limiting dimensions, using the familiar maxwidth=/maxheight=/etc. tags. This is never going to be completely achieved, of course, because draught varies for each bit of the riverbed. ;) The next best thing is to tag the 'gauge' of a waterway - in other words, the largest dimensions that will fit through all the structures on that waterway. In Europe, tagging a waterway with the CEMT class would be a quick-and-dirty-though-not-particularly-accurate way of stating the gauge. (That said, the CEMT class would fit very well in the designation= tag.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/U-S-inland-waterways-tp5709017p5709046.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U.S. inland waterways
I found this at http://www.ndc.iwr.usace.army.mil/data/dictionary/ddnwn.htm Data is here http://www.ndc.iwr.usace.army.mil//db/waternet/data/ but not in shp format so someone would need to do some format translation. There are lots of other sets of data and perhaps one of those has something even more along the lines you want. All the USACE data and NOAA data should be public domain the same as tiger, but some investigation should be done before using any specif source. The metadata for this list use and access restrictions as none. Attribute: Attribute_Label: GEO Attribute_Definition: Geographic Class Attribute_Definition_Source: USACE Attribute_Domain_Values: Attribute: character Enumerated_Domain: Enumerated_Domain_Value: G = Great Lakes O = Ocean / Offshore I = Inland Attribute_Label: FUNC Attribute_Definition: Functional Class Attribute_Definition_Source: USACE Attribute_Domain_Values: Attribute: character Enumerated_Domain: Enumerated_Domain_Value: Nno traffic, non-navigable Sshallow draft (i.e., no deep draft ocean vessels) Ddeep draft Bboth Uspecial vessels only (fishing, pleasure craft, etc; normally no freight traffic) Attribute_Label: WTYPE Attribute_Definition: Waterway Type Attribute_Definition_Source: USACE Attribute_Domain_Values: integer Enumerated_Domain: Enumerated_Domain_Value: 1 - Harbor (including harbor channels), Bay 2 - Intracoastal Waterway 3 - Sealane 4 - Sealane with separation zone 5 - Open water 6 - River, creek, thoroughfare, lake 7 - Estuary 8 - Channel (not including harbor channels) 9 - Canal 10 - Great Lakes direct link (major ports) 11 - Great Lakes indirect link 12 - Corps of Engineers Lock On Wed, May 16, 2012 at 4:22 PM, Nathan Edgars II nerou...@gmail.comwrote: On 5/16/2012 1:06 AM, Jeffrey Ollie wrote: I guess that depends on what you're trying to do... If you are trying to tag the largest possible vessel that can navigate a waterway (under normal conditions at least) you could probably come up with a reasonable set of tags. Inland waterways are highly dynamic though... The Army Corps has well-defined channels that they regularly dredge to a specified depth and width. Can this be matched to some sort of barge classification? __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U.S. inland waterways
You might check with the OpenSeaMap guys On Wed, May 16, 2012 at 7:20 PM, Nathan Edgars II nerou...@gmail.comwrote: On 5/16/2012 6:48 PM, Dale Puch wrote: I found this at http://www.ndc.iwr.usace.army.** mil/data/dictionary/ddnwn.htmhttp://www.ndc.iwr.usace.army.mil/data/dictionary/ddnwn.htm Data is here http://www.ndc.iwr.usace.army.**mil//db/waternet/data/http://www.ndc.iwr.usace.army.mil//db/waternet/data/but not in shp format so someone would need to do some format translation. There are lots of other sets of data and perhaps one of those has something even more along the lines you want. Thanks for the link. I found it in shapefile format: http://www.bts.gov/** publications/national_**transportation_atlas_database/**2011/http://www.bts.gov/publications/national_transportation_atlas_database/2011/ So far the depths seem to jibe with other sources, and the functional class looks like a good way to classify waterways, absent more specific local regulations. Any objections to continuing to use ship=yes for navigable waterways, and a new deep_draft=* tag for ocean vessels? -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
=Avenue E South way id=11234533 name v=SE Ave K Pl -- tiger:name_base v=SE tiger:name_type v=Ave way id=11200345 name v=SE Ave F Pl way id=11100255 name v=SE Summerfield Way; Summerfield Way way id=11298967 name v=SE W Snow Rd way id=10244663 name v=SE182 Ave way id=11121266 name v=SW 108th Stcr -- name_1 v=SW 108th St way id=11156351 name v=SW 108th Stcr N way id=11167562 name v=SW 112th Cir Ln S way id=11032640 name v=SW 28th Ter; SE 28th Ter way id=11107394 name v=SW Dr Martin L King Jr Dr way id=11101573 name v=SW St George St way id=10767432 name v=Saint St SE way id=10777261 name v=Scallop Dr; George J King Blvd; Glen Cheek Dr way id=10762071 name v=W 33rd St W way id=10763371 name v=W 30th St W On Fri, May 11, 2012 at 7:38 PM, Serge Wroclawski emac...@gmail.com wrote: On Fri, May 11, 2012 at 4:17 PM, Dale Puch dale.p...@gmail.com wrote: I understand the script checks for only one instance of the abbreviation. My point was what is someone manually expanded ONE of the abbreviations, leaving st something street? Is that checked for? I have a number of thoughts here: 1. Real world examples. Many of the examples I've seen are contrived. I'm glad we're testing, but testing needs to be based on actual data seen in the US dataset. That said: 2. There are a couple of ways to handle this: * One way (the most conservative way) would be to test for untouched TIGER ways. That is ways in which they're still at version 1. This would be a real problem, though, since there are lots of examples were someone may have fixed the geometry without touching the tags. * The other way is a method I'm using in an experimental branch of the code on my machine, which is to try to be a bit more selective about the expansions of road types. If we assume that the road type always appears after the base name, we can be handle examples like (real world example) St Marys St. The same would hold true for direction tags, so we'd be able to expand E E St confidently as well. But there's a catch. If someone would have edited the name of the above street from the original St Marys St to St. Marys St then that test would fail, and the expansion would never occur, where as in the current version, it would. So: 3. Any method used is going to produce some number of potential either false positives or false negatives. I contend that the number of errors in either case will be so tiny that it will be lost in the noise, but there's no way to promise it will always be 0. The best we can do is toss out uncertain expansions and have them handled manually (which is something I'm working to make better in the next version of the code as well). But: 4. I don't want us to rely on cleverness. I'd much rather rely on people testing the code with real world inputs and checking the outputs. I should have a new version of the code either tonight or tomorrow, with the new expansion rules. - Serge -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Fixing TIGER street name abbreviations
But Serge IS testing. He is building and testing a script that is conservative and gives feedback on what it isn't sure about. That info can be used for future scripts, or manual edits. He is only editing ways originally imported by tiger, based on the tiger prefix, suffix, road type, and base name. If all were rev 1 unedited imports it would work darn well. The testing is mostly for bad tiger data and subsequent edits that confuse things. Your just saying it cant/shouldn't be done, and he is figuring out a way to make it work correctly. Let him do his tests and provide results, and then you can try and find the faults in that rather than telling him to not try. He isn't running this on the live DB so why not encourage/help him produce better results. If there are things you know that will cause problems, provide real examples of it so he can edit and test the script to handle them or gracefully skip those. On Sat, May 12, 2012 at 6:51 AM, Anthony o...@inbox.org wrote: The examples are contrived because we're not testing. We're pointing out why this is a bad idea. Using real world examples would just encourage people to fix those examples and ignore the fact that the process is wrong. Anyway, you realize that the road type doesn't always appear after the base name, right? -- Forwarded message -- From: *Serge Wroclawski* Date: Friday, May 11, 2012 Subject: [Talk-us] Fixing TIGER street name abbreviations To: Dale Puch dale.p...@gmail.com Cc: talk-us@openstreetmap.org On Fri, May 11, 2012 at 4:17 PM, Dale Puch dale.p...@gmail.com wrote: I understand the script checks for only one instance of the abbreviation. My point was what is someone manually expanded ONE of the abbreviations, leaving st something street? Is that checked for? I have a number of thoughts here: 1. Real world examples. Many of the examples I've seen are contrived. I'm glad we're testing, but testing needs to be based on actual data seen in the US dataset. That said: 2. There are a couple of ways to handle this: * One way (the most conservative way) would be to test for untouched TIGER ways. That is ways in which they're still at version 1. This would be a real problem, though, since there are lots of examples were someone may have fixed the geometry without touching the tags. * The other way is a method I'm using in an experimental branch of the code on my machine, which is to try to be a bit more selective about the expansions of road types. If we assume that the road type always appears after the base name, we can be handle examples like (real world example) St Marys St. The same would hold true for direction tags, so we'd be able to expand E E St confidently as well. But there's a catch. If someone would have edited the name of the above street from the original St Marys St to St. Marys St then that test would fail, and the expansion would never occur, where as in the current version, it would. So: 3. Any method used is going to produce some number of potential either false positives or false negatives. I contend that the number of errors in either case will be so tiny that it will be lost in the noise, but there's no way to promise it will always be 0. The best we can do is toss out uncertain expansions and have them handled manually (which is something I'm working to make better in the next version of the code as well). But: 4. I don't want us to rely on cleverness. I'd much rather rely on people testing the code with real world inputs and checking the outputs. I should have a new version of the code either tonight or tomorrow, with the new expansion rules. - Serge ___ 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 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
I understand the script checks for only one instance of the abbreviation. My point was what is someone manually expanded ONE of the abbreviations, leaving st something street? Is that checked for? The question also applies to Dr something Dr previously changed to Dr something Drive, and possibly directionals as well. Serge seems to be doing a good job with this, and this is just feedback so there aren't any incorrect expansions. On Fri, May 11, 2012 at 12:27 AM, Toby Murray toby.mur...@gmail.com wrote: On Thu, May 10, 2012 at 10:52 PM, Dale Puch dale.p...@gmail.com wrote: I think I came up with a rare possibility for error. The original st something st was manually expanded to st something street your checking for a single st, and there would be. Or am I missing another check? It checks for one and ONLY one possible abbreviation to expand. If there are more than one it punts and ignores the way. This is a very conservative approach which is probably good at least for a first pass. Maybe if the first run goes well we can see how many problems are left and look at refining things for a second pass to catch more difficult ones. Or not... Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
Sorry, I should have been clearer, the results I posted were from my quick test. I just wanted to report the abbreviations I saw as possible additions to the list in Serge's script. And to give an idea of which showed up most either for scripting or if someone wanted to handle the lesser used ones manually. On Thu, May 10, 2012 at 6:25 PM, Serge Wroclawski emac...@gmail.com wrote: On Thu, May 10, 2012 at 6:08 PM, Mike N nice...@att.net wrote: On 5/10/2012 4:08 PM, Serge Wroclawski wrote: I've been testing a script to do this. Here it is: Thanks for posting it. I don't see where it expands directionals; I don't see the same thing Dale saw: 5141 instances of E changed to East for example. It doesn't expand directionals, and it only touches ways with tiger tags, so I suspect Dale is looking at the wrong code, or the wrong output, or something else. If it doesn't expand directionals, I believe that it should where the TIGER hint is available tiger:name_direction_prefix. Otherwise we'll still end up with endless nagging over Okay, let's talk about this then. It was originally outside the scope of our discussion, but I'm happy to add it- it won't be more than a another few lines of code and another lookup table. Warning - abbreviation in 'E Pond Scum Street' when uploading. Please do not upload the output! 1. We should all agree on the correct output. 2. We should organize the right account to upload with. 3. We should add tags to the uploaded changesets. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
The issue with abbreviations is very muddy. BUT it has been said many time that we do not want to abbreviate where possible. There are several reasons. - Clarity! The abbreviations are just that, they mean the full word, and are spoken that way, but written and displayed as the abbreviation. I also disagree I have never know anyone that said whatever A V E they do not spell it out, they say the word the abbreviation stands for. Same for St, Dr ect. - It is a LOT easier to abbreviate from the full word than to go the other way. Otherwise this scripting expansion thing would be easy and error free. - As mentioned it makes use of the data easier, especially for searching, and text to speech. Yes there can be errors with going from abbreviations to the full words. A reason for doing this as said, do it once with review instead of in every program that uses the data. But those errors are small in comparison to the number of abbreviated way names and can be corrected later as found just like any other tagging error. Most of those errors are going to be on names that are unclear to begin with. People have gotten so gun shy of any automation or imports that I feel they are actively blocking people trying to do the right thing and a good job. It is almost to a point I wonder why someone would go thru talking it over on the list if you get grief for it if you can just quietly start doing it. Obviously not what we want. On Thu, May 10, 2012 at 10:56 PM, Anthony o...@inbox.org wrote: On Thu, May 10, 2012 at 10:45 PM, Mike N nice...@att.net wrote: But you wouldn't be confused if an stranger came in asking how to get to Whatever Avenue?If not, then there's no problem with the expansion. Okay, so basically we're ignoring the on-the-ground rule in order to map for the renderer. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
I think I came up with a rare possibility for error. The original st something st was manually expanded to st something street your checking for a single st, and there would be. Or am I missing another check? I can't think of any other situations besides Saint and Street like this. Possibly check it is at the end of the name or only followed by a N S E ect. Or just save those for a second pass at expanding either by another script or by hand. On Thu, May 10, 2012 at 4:08 PM, Serge Wroclawski emac...@gmail.com wrote: I've been testing a script to do this. Here it is: http://www.emacsen.net/tiger.py It needs to be fed a file. I've been using the state files from geofabrik. the resulting files in expansions can then be fed to a script for upload. I welcome feedback on the script and the resulting output. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
Some of the problem my be a disconnect between county level mapping/import talk and the country level talk. I personally like imports that are done well, but also understand how poor imports can make things harder for everyone. It looks like you guys have done a lot of work and many improvements, and this is meant in a constructive light. I do not want to discourage anyone, just get anyone making imports to measure three or four times before cutting ;) I see two entries on http://wiki.openstreetmap.org/wiki/Import/Cataloguefor California (that link to the California imports) but several more on the http://wiki.openstreetmap.org/wiki/California/Import page. Then even more on http://wiki.openstreetmap.org/wiki/Santa_Cruz_County,_Californiabut no links to that from either. How much feedback did you get from other importers or mappers outside your local group? One way to put it is how many people outside of the ones specifically brought into the discussion commented on the imports, or even realized they were happening? Would better planning and feedback have meant the import was uploaded and DID NOT need lots of fix-up? It is a lot easier to play with the data before uploading than it is after it is in the OSM database. Dale On Thu, Apr 26, 2012 at 6:26 PM, stevea stevea...@softworkers.com wrote: WernerP wrote: User nmixter has been the user who did the import. I would recommend to revert the changeset(s) and delete the useless stuff. In the small area I checked there were many errors (overlapping lines, double nodes...). I agree, that there is no way to fix stuff. User BiIbo modified many objects (about 33 %), but it is not obvious what he really changed. ...I think we should simply delete all objects without any osm-tags. User nmixter, in addition to being a friend of mine and frequent hiking buddy so we can upload our GPS tracks from the hike into OSM (what I consider real OSM mapping) is likely one of the top contributors of OSM data on Earth. Really, by number of uploads, he may be the project's #1 contributor (or was at one point in time). That said, I offer the following (not brief) history as deeper insight, not as mean-spirited or holier-than-thou. Nathan (Mixter) is a very earnest fellow when it comes to OSM. I believe him to have the utmost respect for our project, and he really wants the map to bloom as he puts it. Reading http://wiki.openstreetmap.org/** wiki/California/Importhttp://wiki.openstreetmap.org/wiki/California/Import, he talks about ongoing imports, usually county-at-a-time, using data which he scrupulously finds and decides to use only as he believes it from official sources and being of reasonable quality (or which, as I keep saying can be MADE INTO reasonable quality data). He talks about turning the state brown (California Farm Bureau data) and turning the state green (California State Department of Conservation Farmland Mapping and Monitoring Program, FMMP data). He did help user:Apo42 (another hiking buddy of ours) well-integrate the Mid-Peninsula Regional Open Space Distric data so that much of that parkland (except closed-to-public areas) appears on the map, and offered good consensus (let's agree with MROSD that we shouldn't enter into OSM the closed-to-public areas, as did I) that Apo use a landuse=common tag on these not-quite-leisure=park areas; Nathan is no stranger when it comes to good discussion and offering and listening to a greater sense of consensus BEFORE he does an import/bulk upload. He also has worked with me extensively on the import of the Santa Cruz County GIS Department's official landuse data into OSM, the process of which we have documented extensively at http://wiki.openstreetmap.org/** wiki/Santa_Cruz_County,_**Californiahttp://wiki.openstreetmap.org/wiki/Santa_Cruz_County,_California. The way Nathan did this was an initial upload (which was fraught with technical problems), revert those (but not completely), do the second upload (which was better, but still filled with noisy data), and then worked closely with me on fixing up the data. Nathan might have done 10% to 20% of the fix-up, but I did the other 80% to 90% (having lived in Santa Cruz County for many decades) and it has taken me the better part of two years of rather frequent OSM editing to do so. During this time, Santa Cruz won a Gold Star award on BestOfOSM.org (one of just a handful in North America) for nearly perfect landuse but I myself will say that was not without huge effort on my part to correct thousands of serious mistakes in Nathan's import. Nonetheless, he-and-I-together made a large part of this possible. (Of course, we also stand on many shoulders of other OSM contributors!) My point is that OSM + TIGER + TIGER-cleanup + early contributors + a noisy but OK import + some cleanup by the importer + years of local love in editing by yours truly (or anybody) = a Gold Star award! So, imports, done well
Re: [Talk-us] tiff, dwg and nad83
Regarding Frederik's 4 points, plus the element duplication issue as reasons imports are bad: ALL are potentially true for any mapper especially new ones. It is just that a bad import can generate a lot more good/bad data at once. So yes, imports need more effort to insure good quality. Regarding dupe items, this is both import related and upload related. The import side is obvious, but failed uploads of any source have generated lots of duplicates as well. This is admittedly more prone with imported data, I would guess fewer users doing manual edits tried to make large uploads. See the notes below for the rest. On Mon, Apr 16, 2012 at 8:30 PM, Serge Wroclawski emac...@gmail.com wrote: On Mon, Apr 16, 2012 at 6:46 PM, Frederik Ramm frede...@remote.org wrote: I think this point is controversial, so let's stick with some points that aren't: 1. In our history of imports, a very small percentage have been good. Compare a users early imports to their early mapping 2. We have no current technology to keep an import synced with another data source, so the data goes stale quickly. Also true for manual edits. Why is this considered just an import issue? 3. Many imports are of datasets we don't want in OSM and we have little/no mechanism outside community vetting to discover that until it's too late. Any user can decide that they want to include X into the dataset imported or manually mapped. 4. Most imports are bad, and most imports are left in OSM, which means we have tons of garbage in OSM. Garbage in OSM makes the map harder to work with for mappers, for tool-makers and for users. see all above - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
Documentation! I think what you did is exactly what is needed. It may or may not need improvements. If what is decided in the newsgroups is not put down in the wiki then the discussion was not finished to a point someone could sum it up for the masses to follow. Then post a link here for everyone to review. There are always different types of people. Some need step by step instructions, other just an overview and they research it from there. Sometimes simply stating which type of instructions before starting is fine. If it is something that others will need to know then make a wiki page and answer by pointing them there. Especially if it took much work to answer the question. Stating up front: Importing is generally a technical endeavor and anyone not willing to do a bit of digging to learn new things will find it frustrating. This is just an overview of the steps. Detailed instructions for some or all of the steps may be on the wiki under imports (link) and learning to use each piece of software may also be required. That said great software design would make imports easy... It just take a great programmer that understands the beginner mapper, but can map with the masters and a LOT of programming. :p Dale On Sun, Apr 15, 2012 at 9:10 PM, Josh Doe j...@joshdoe.com wrote: On Sun, Apr 15, 2012 at 2:37 PM, Charlotte Wolter techl...@techlady.com wrote: The exchange between Frank Cox and others about importing data is a perfect example of an ongoing problem with this list: Many of the discussions and answers are simply too GIS geeky for the vast majority of us. I'm not entirely sure this is helping to address your concerns, but I just created a checklist for importing which should help: http://wiki.openstreetmap.org/wiki/Import/Guidelines#A_checklist The goal is to provide a quick overview of the steps in importing data. This can certainly be expanded, so please do so. Replies should probably go to the imports@ list rather than talk-us@, since it's not talk-us@ specific. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
A stray thought regarding bot edits, sorry for the new tangent. It is more involved for the bot authors, but have them e-mail the owner of the offending item(s) with what is wrong, a link to the item, link so the bot fixes it automatically, author will fix it or remove it from the list as being correct. The default being automatic fix in 2 weeks if no reply. Limit the e-mail size, and instead include a partial list and a link to a larger list if the size was exceeded. There is a fair potential for spam with this, so it would need a bit of oversight. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Announcement: Address Improvement project
Are you sure it is omitted, and not just a tiny dataset ( say 30 ) since I think there are only a few Disney executives residences there? On Wed, Oct 5, 2011 at 9:35 PM, Nathan Edgars II nerou...@gmail.com wrote: On 10/5/2011 9:15 PM, Metcalf, Calvin (DOT) wrote: In MA they are good in they are precise How have you tested this? don't know about the rest of the country but say wht you will about the census they tend to get the areas right in the sense of getting all the houses. In Florida, they omit 32830, which has been Walt Disney World's zip code since it opened in 1971. __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
Response I received in 2008 GIS data provided by the FDOT Transportation Statistics Office isconsidered to be in the public domain and can be used for any purpose. http://wiki.openstreetmap.org/wiki/Talk:Potential_Datasources#Copy_of_email_from_FDOT I had looked at this a while back and gave up on it personally due to the high amount of manual activity needed. I just did not have the time to do much with it. Not to mention the problems of keeping track of what had been worked on. Would you walk thru your process steps so I and perhaps others could learn from them? For me it was partly an issue of the data covering a large land area, then only able to download small chunks from OSM to edit. Anything else and JOSM took so long to do anything (this is better now, but I think still true). Constantly switching between the layers to get the info, then back to edit the OSM data to match... It all just seemed way more labor intensive than it needed to be. Anyways that is why I am interested in how you plan to attack it. -- Dale Puch On Wed, Aug 31, 2011 at 7:47 PM, Nathan Edgars II nerou...@gmail.comwrote: http://www.dot.state.fl.us/**planning/statistics/gis/**roaddata.shtmhttp://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm This is public domain per Microdecisions, Inc. v. Skinner (though I'm waiting on a reply from FDOT confirming that they agree). After checking all current maxspeed tags against the data to ensure accuracy, I plan to use this as a background layer in JOSM and manually split existing ways at speed limit changes. Tags added will be maxspeed=* and source:maxspeed=FDOT Maximum Speed Limits GIS data, updated August 27, 2011: http://www.dot.state.fl.us/**planning/statistics/gis/**roaddata.shtmhttp://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm I will only do this for state roads, as a quick look shows that it cannot be relied on for county roads. I may in the future add other tags from the same data, such as access management. __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
Oh, I forgot to mention they list the files as being updated weekly. So apparently what ever changes they make that week get rolled into the data. So make sure to start with a current set of data. On Wed, Aug 31, 2011 at 9:57 PM, Dale Puch dale.p...@gmail.com wrote: Response I received in 2008 GIS data provided by the FDOT Transportation Statistics Office isconsidered to be in the public domain and can be used for any purpose. http://wiki.openstreetmap.org/wiki/Talk:Potential_Datasources#Copy_of_email_from_FDOT I had looked at this a while back and gave up on it personally due to the high amount of manual activity needed. I just did not have the time to do much with it. Not to mention the problems of keeping track of what had been worked on. Would you walk thru your process steps so I and perhaps others could learn from them? For me it was partly an issue of the data covering a large land area, then only able to download small chunks from OSM to edit. Anything else and JOSM took so long to do anything (this is better now, but I think still true). Constantly switching between the layers to get the info, then back to edit the OSM data to match... It all just seemed way more labor intensive than it needed to be. Anyways that is why I am interested in how you plan to attack it. -- Dale Puch On Wed, Aug 31, 2011 at 7:47 PM, Nathan Edgars II nerou...@gmail.comwrote: http://www.dot.state.fl.us/**planning/statistics/gis/**roaddata.shtmhttp://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm This is public domain per Microdecisions, Inc. v. Skinner (though I'm waiting on a reply from FDOT confirming that they agree). After checking all current maxspeed tags against the data to ensure accuracy, I plan to use this as a background layer in JOSM and manually split existing ways at speed limit changes. Tags added will be maxspeed=* and source:maxspeed=FDOT Maximum Speed Limits GIS data, updated August 27, 2011: http://www.dot.state.fl.us/**planning/statistics/gis/** roaddata.shtmhttp://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm I will only do this for state roads, as a quick look shows that it cannot be relied on for county roads. I may in the future add other tags from the same data, such as access management. __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
So a query to http://www.overpass-api.de/query_form.html union query type=relation has-kv k=network v=US:FL/ /query recurse type=relation-node into=nodes/ recurse type=relation-way/ recurse type=way-node/ /union print/ Returns all relations with [network=US:FL], as well as the ways and nodes If a way with [network=US:FL] is NOT in a relation, will it be returned by this? Would it need a second query type=way section? Is this resultant file just like the data normally downloaded by JOSM? IE. edit it the same, then upload? Dealing with such a large area, will conflict resolution be an issue? I really have not had to deal with it before, so do not know how big a deal that is. On Wed, Aug 31, 2011 at 9:59 PM, Nathan Edgars II nerou...@gmail.comwrote: US:FL -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
Ahh right that is why there is US:US It gives a logical and consistent construction as well as delineated fields for building the name with the ability to make state specific shield rules based on it. -- Dale Puch On Wed, Aug 24, 2011 at 3:37 PM, Jason Straub strau...@yahoo.com wrote: As the person that just got done labelling each TX state highway, I'll chime in here with some comments. For the network tag, I think that the labelling should be (country : state network : network within the state : subnetwork in state), while the ref is JUST the number for that highway. So: US:I - Interstate US:I:BUS - Business Interstate US:US - US Route US:US:BUS - Business US Route US:US:ALT:BUS - Business Alt US Route US:TX - Texas State Highway US:TX:FM - Farm to Market US:TX:RM - Ranch To Market US:TX:FM:Bus - Business Farm to Market Having been through most of the highways in TX at least, this works for all that i've labelled, whether it's still that way or not. I prefer to have the final labels show the state abbreviation and number (TX 10) instead of generic state labeling (SH 10) (TX has state highways, not state routes), but am willing to work with either. Once a useful mapping tiling appears that uses state shields, this wont matter nearly as much. Jason 25or6to4 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
The scheme sounds simple enough at first but is it robust and usable? If not what would it take to make it so? Here are some of my thought on it. The way I see it you take the last element of the network tag (FARM in this case) and that is the network. Ref is the ID in that network The first part of the network tag is the location that isolates the network to make it unique. Those would be the rules to create the tags, and to parse it. This works well for relations witch only have one route. For ways, that will always be a mess if more than one route. Either just put the primary, or comma separate them as a reference just for repairing broken relations. So would this actually work for all situations? Or at least enough that the exceptions are small enough to live with? network=US:TX:SR ref=10 = Texas State road 10 network=US:FL:Orange:CR ref=10 = Florida Orange county road 10 network=US:TX:FARM ref=10 = Texas State Farm road 10 Wouldn't this just use one US in network? network=US:BUSINESS ref=50 = US Business 50 Or should this really just be broken into a third tag? Location/controlling body (US, State, county ect.) Network and Ref? What would be a good tag name for that? How would the county names be handled/abbreviated? How will this affect maps and software for parsing the tag info? Will it make it easier or harder to display names/shields to local standards. On Tue, Aug 23, 2011 at 9:31 AM, Craig Hinners cr...@hinnerspace.comwrote: Alan Mintz alan_mintz+...@earthlink.net For FM 1960, I'd use: network=US:TX ref=FM 1960 I'd prefer to put all of the network information in the network tag, keeping the ref tag as a pure container for the unique designation within the network: network=US:TX:FARM ref=1960 Similarly, instead of this style of tagging of US business routes (example found in Salisbury, MD): network=US:US ref=50 Business I'd prefer: network=US:US:BUSINESS ref=50 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another case of JOSM ignoring US tagging standards
Perhaps Mike (or Ian) could document this setting on the wiki, and why it should be used. So is the JOSM default behavior correct for outside of the US? Would it be correct for most of the world to have the default changed, or do we really just need a set of custom US settings that can be toggled on or loaded? Perhaps some custom presets tool bars as well? If it is something that JOSM should change or add, a bug report would be the best action. Pointing to the wiki entry as reference would probably help and suggest revising the entry if the bug is fixed. I would think that would cover both the immediate solution, and a long term one. -- Dale Puch On Mon, Aug 8, 2011 at 12:27 PM, Mike N nice...@att.net wrote: On 8/8/2011 11:41 AM, Ian Dees wrote: Dirk added a hidden preference so you can specify your own list of roles to ignore this warning for. See [0], but if you set an advanced preference of way.split.roles.nowarn in JOSM's preference pane with a comma-separated list of roles it appears it will not show that warning. [0] https://josm.openstreetmap.de/**changeset/4254/josmhttps://josm.openstreetmap.de/changeset/4254/josm One small detail, the comma-separated list of roles should actually be entered as one role per line. (Tested and it works) __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Which county next?
A few suggestions: - A way to move the pointer without submitting the location. In case the pointer is hiding something. Or perhaps a checkbox to temporarily hide the pointer - You have a skip button, but no way to determine why it was skipped. Perhaps add buttons or check boxes for the reason it was skipped. This will allow revisiting those items that need it by issue, like if better images become available, or better methods for identifying the point. Possibly even manually surveying the points. I think this is an important one to add. Possible skip reasons I can think of. Poor image, empty parcel, correct location, can't identify location from sat view (apartment, multiple entrances, multiple buildings ect.) - Can you overlay a parcel outline to positively identify which parcel (and it's limits) this refers to. On Wed, Jun 8, 2011 at 3:43 PM, Alan Mintz alan_mintz+...@earthlink.netwrote: At 2011-06-08 10:57, Steve Coast wrote: Who says it's being done for driving directions? Is that/will that not be a popular use for OSM? It does not make walking directions impossible - just requires the addition of the driveway to the map. OTOH, putting the pin on the front door of a building inside a large parcel may well leave a driver lost and quite a distance from where he needs to be. On 6/7/2011 3:28 PM, Alan Mintz wrote: The site allows you to drag a pin from where we think an address currently is to the front door of the property Is that really where we want the pin to be for driving directions? I've mostly tended to either putting the address info on a complete landuse polygon, or if a point, placing it on the driveway, just off the street to which it connects. I swear I read this somewhere as standard practice, and it makes sense from a navigation standpoint, particularly for rural parcels, where a driveway can be hundreds of meters long and not mapped. San Diego County, CA, USA has a bunch of address data from a SanGIS import. -- Alan Mintz alan_mintz+...@earthlink.net ___ 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 -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
I have only skimmed these messages, so forgive me if it was already brought up. There are two criteria I do not think were brought up. Length of a road, ie is it important for the city, county, state, or country. This needs to be balanced with the width, and other features of the road like intersections ect. The other is relative importance of the road. I know this is subjective, but for places without many roads, even a dirt road might be a main connector between points. In the end this is a map, and it needs to inform of the best roads to get from place to place. This will depend on the map scale and distance traveled. Longer roads, especially ones with good throughput should generally be the higher class roads. Dale On Tue, May 31, 2011 at 10:37 AM, Kristian Zoerhoff kristian.zoerh...@gmail.com wrote: I hate it when I forget to hit Reply-All On Tue, May 31, 2011 at 8:54 AM, Greg Troxel g...@ir.bbn.com wrote: Kristian Zoerhoff kristian.zoerh...@gmail.com writes: On Mon, May 30, 2011 at 10:41 PM, Toby Murray toby.mur...@gmail.com wrote: On Sun, May 29, 2011 at 4:05 PM, Nathan Mills nat...@nwacg.net wrote: On Sun, 29 May 2011 12:09:30 -0700, Paul Johnson wrote: I'm thinking the differences between motorways and trunks are minor. Trunks may have intersections, motorways don't. That's the simple way to state my opinion. It also seemed to be the thrust of most of the discussion on the talk page of the wiki page referenced previously as closest to consensus (the page itself just references the existence of the two camps and leaves it at that). In short, my position is simply that an end user expects a trunk road to be identifiably different than primary or secondary. That's how it's done on other maps, so I don't see why that's such a bad thing here. I agree with this as well. And I too thought this was a pretty widely accepted convention. That's one accepted convention, to be sure, but it sometimes ignores the realities of where traffic goes. To give an example: http://osm.org/go/ZUdwt69 IL 72 (the secondary at the top of the map) is a 4- to 6-lane at-grade expressway; wide median, lights only every mile or so, speed limit up to 55 mph. It carries a fair amount of traffic, but because it parallels I 90 (a toll road here), it really only peaks at rush hour, when the toll road is near capacity.. US 20 (the trunk at the map bottom), is a 4-lane, non-divided road, but it carries far more traffic than 72, as it connects the two motorways at the map ends (the Elgin-O'Hare Expressway, and the Elgin Bypass, which were never connected). It's not particularly distinguishable from a lesser 4-lane road, aside from the absurd amount of traffic it carries. If we stuck purely to the above convention, 72 would be trunk, and 20 would be primary (at best). But But what's wrong with that? It sounds like IL 72 is a higher-class road in terms of the physical road, and US 20 doesn't seem to have almost-motorway features. Just because a road that is properly labeled primary is heavily used doesn't make it a higher class; you certainly wouldn't label it a motorway based on traffic count. No, but motorways are such a special case of highway I really don't think we should use them as a basis of comparison. You're either a motorway, or you aren't. traffic flow cares more about where the road goes, not what it looks like. Sure, and routers can use that. Probably we need to completely decouple nominal importance in the hierarchy of road types physical characteristics importance to the people who use it Haven't we already? Physical characteristics have tags (surface, lanes, maxspeed). It's the hierarchy that seems to be the sticking point, and that's exactly what I thought classification was. -- Kristian Zoerhoff kristian.zoerh...@gmail.com ___ 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] Another day, another bad import
I see 4 related but different issues here. - New users (or un-noticed users that make poor edits) that cause problems for several reasons. - bots having unintended consequences - new to import users (like the first one but at a new level) - poor tools or instructions on making use of those tools Possible ideas for dealing with these. For new users, Simple and specific type instructions. My understanding is most users start with wanting to add/fix things they are familiar with. So specific instructions for those things, with links to videos if possible, and possibly for each of the major editors (potlatch, JOSM, merkator...) Make and intro video (1-3 min.) almost mandatory for new users when they sign up. A quick welcome, overview of the project, and point out where to find the instructions above to help them with what they want to do. Limit new users to some max number of changes per change set. If they go over, they have a warning about it but can proceed after clicking thru it. That change set could be flagged for review by some volunteers for that task. If they go thru training (instruction material mentioned above) the limit is removed. For bots and imports, try something similar. Limit what they can do until reviewing some good instructions. This relies on *up to date, and quality instructions* being read and followed. Some sort of tracking for training a user has gone thru as well as an honor system for that training. Determining what a user is doing but number of changes per set and/or what tools they are using. The instructions and getting people to use them are probably the best place to put effort. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Caltrans exit numbers
On Mon, Mar 28, 2011 at 1:08 PM, Apollinaris Schoell ascho...@gmail.comwrote: Santa Clara county was sued successfully, but not on a federal level. State of California has the same PD rules and this can be used only for California state and county data. Don't have the link available right now but it can be found in the archives of talk-us But still you may need to check data offered at CASIL website. It is a mix of state and data provided by private companies. One example is Greeninfo data which is not PD. On Mon, Mar 28, 2011 at 9:15 AM, Alan Mintz alan_mintz+...@earthlink.netwrote: At 2011-03-23 04:22, Dale Puch wrote: A quick note, do not confuse public records as always meaning public domain. Some states may not have laws specifically preventing agencies from claiming copyright, not apply to all levels of government, or have exceptions to which works. IE. I think it was Michigan that specifically copyrights it's gis data. Some offical state clearinghouses may claim copyright on what should be public domain from the various agencies. http://wiki.openstreetmap.org/wiki/Potential_Datasources#U.S. is the best compilation of sources and notes about them I know of for our use. I would suggest to update it with any information you come up with. Hasn't there been recent case law, though, that enforces a federal principle (?) that any data produced by a government agency must be public domain (excepting obvious things like national security)? Wasn't Santa Clara County, California sued successfully? -- Alan Mintz alan_mintz+...@earthlink.net ___ 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 I know both Florida and California have state laws that by default make public records = public domain (uncopyrightable by state or local gov.) this does NOT include data generated by sub contractors for the governments use. They also allow for exclusion due to security. I think they also provide a loophole for specific situations that would allow a copyright, but I don't remember any details of that. AKA an ugly mess because they rarely specifically state the status of any data. Open access is not always the same as public domain either. http://sunshinereview.org/index.php/State_sunshine_laws looks to be a good starting point. http://en.wikipedia.org/wiki/Freedom_of_information_legislation -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Caltrans exit numbers
A quick note, do not confuse public records as always meaning public domain. Some states may not have laws specifically preventing agencies from claiming copyright, not apply to all levels of government, or have exceptions to which works. IE. I think it was Michigan that specifically copyrights it's gis data. Some offical state clearinghouses may claim copyright on what should be public domain from the various agencies. http://wiki.openstreetmap.org/wiki/Potential_Datasources#U.S. is the best compilation of sources and notes about them I know of for our use. I would suggest to update it with any information you come up with. -- Dale Puch On Tue, Mar 22, 2011 at 6:58 PM, Paul Johnson ba...@ursamundi.org wrote: On 03/22/2011 01:13 AM, Andrew Cleveland wrote: Thanks. The only indication I can find other than the statement on ca.gov is that Wikipedia takes anything created by the state of California obtained as public record to be in the public domain ( http://en.wikipedia.org/wiki/Template:PD-CAGov ). So I think it is a fair assumption that the exit data is public domain as well (though I'm not a lawyer obviously). I'd love to see a list of states whose data isn't public domain, since I'm hazarding to guess that list is much smaller. ___ 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] Bike / Pedestrian directions on the MQ Open sites
On Fri, Mar 4, 2011 at 9:39 AM, Richard Fairhurst rich...@systemed.netwrote: Antony Pegg write: just a quick note - we've added bicycle and pedestrian routing options to the MapQuest Open sites This will no doubt provoke the usual tirade of but but but but, so can I just step in here and post an unqualified awesome. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Bike-Pedestrian-directions-on-the-MQ-Open-sites-tp6088561p6088668.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us I second that sentiment. Great addition. Now to add more data for this. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD Hydro Connectors
The default render should be with connectors below the water bodies. AKA render issue. Possibly there should be some way to force it to render on top, and that would probably need a new tag. The main reason would be to show the navigation route if it is restricted or complicated. Shallow water with a canal, or large complicated reservoir would be 2 examples. This should also be discussed with the openseamap people since it is primary for water navigation and they have the knowledge to give the best input. I agree using the oneway tag is the wrong approach to show flow direction. Perhaps a flow or current tag. If we want to show that, I think that should also have a separate tag. Basically duplicating the way oneway works. The downside is this would complicate editing and displaying if it was tagged with both. That said, for now using oneway is better than not tagging flow direction. -- Dale Puch On Fri, Feb 18, 2011 at 3:53 PM, Mike N nice...@att.net wrote: On 2/18/2011 3:43 PM, Paul Norman wrote: Here in Canada with the NHN import the portion of streams through lakes and wider rivers were imported with sub_sea=stream sub_sea:type=inferred oneway=yes There is some disagreement about using oneway=yes, presumably to match the stream flow. There is always the possibility of needing to indicate a one way navigation channel where the direction of travel is upstream only. ___ 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] NoName and Roundabouts
On Fri, Nov 26, 2010 at 6:48 PM, Val Kartchner val...@gmail.com wrote: On Fri, 2010-11-26 at 00:13 -0800, Gregory Arenius wrote: Although most roundabouts aren't considered to be part of a way I there might be some that are named or are considered to be part of one of the attached streets. I would just tag the unnamed roundabouts with noname=yes so that its explicit that they are unnamed. NoName render recognizes the tag as well so it won't render as an error. Cheers, Greg I've tagged the roundabouts as you've suggested. I'll see how it comes out. For a while there, NoName hadn't been rendering. How quickly does NoName render now? Why was the MapLint layer removed from Potlatch? On Fri, 2010-11-26 at 16:16 -0500, Dale Puch wrote: Should it be marked? probably not, but here are two other suggestions. Depending on the situation, perhaps use a mini-roundabout, or make the roundabout a split 1-way section in the main road. What do you mean that it shouldn't be marked? I meant tagged with a name, my fault for not being clear. I didn't mark it as a mini-roundabout because it does not fit this description from the wiki: The mini-roundabout usually does not have an island in the middle but is painted on the road. Not arguing, just trying to present possible alternatives for limited situations. For an example, this is what I was thinking of for the mini-roundabout despite it having an actual island. http://maps.google.com/?ie=UTF8hq=ll=28.550981,-81.373233spn=0.000828,0.00167t=hz=20 And here is a bigger I would consider a full roundabout. http://maps.google.com/?ie=UTF8hq=t=hll=28.533968,-81.182785spn=0.001584,0.003339z=19 I also didn't do a split one-way because the roundabout isn't really either of the ways but a special junction of the two ways. That one I was thinking as more of a hack/workaround than a good suggestion, and I would not even consider it unless one way was definitely predominant. I also like that with the Garmin maps (though not the OSM-derived Garmin maps) you will be told which exit (relative to where you enter) to use for exit. My comments are how I've been tagging roundabouts. This is certainly open for someone changing my mind though. That's most of the reason I ask here. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us The real problem is a roundabout is made of ways, but functionally is used as a junction. The OSM design just does not seem to match. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NoName and Roundabouts
Should it be marked? probably not, but here are two other suggestions. Depending on the situation, perhaps use a mini-roundabout, or make the roundabout a split 1-way section in the main road. On Thu, Nov 25, 2010 at 2:44 PM, Val Kartchner val...@gmail.com wrote: When I do a roundabout it shows up on the NoName renderer as a way with no name. Most roundabouts around here don't have names so they shouldn't be tagged as needing a name. These are tagged with junction=roundabout so this can be used for this special case. Can we get a consensus on this then get it changed? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging bicycle anti-routes
On Thu, Nov 4, 2010 at 4:22 PM, Nathan Edgars II nerou...@gmail.com wrote: If there's a specific intersection or stretch of road that's hazardous to a law-abiding cyclist, consider cycle_hazard=* (like cycle_hazard=door zone or cycle_hazard=bike lane to right of right turn lane). On Thu, Nov 4, 2010 at 3:37 PM, Dale Puch dale.p...@gmail.com wrote: As with many OSM tags, there are objective items to begin the categorization. The final decision though will be at least partly subjective. Class:bicycle is a good start. Perhaps list specific features as a base for the ranking, then things that would drop that to lower rankings. An example of what I mean for starting values. separate paved bike/general path = +3 road with bike lane = +2 road with bike route= +1 road with a good shoulder / bike friendly sidewalk = 0 We shouldn't take sides in the debate over bike facilities. In places where use of a bike lane is mandatory, a street without one can be safer than one with, since a cyclist on the former is able to cycle defensively. (A sidepath is even worse - since it's not part of the actual road, a safe cyclist has to yield to turning traffic at every intersection and driveway.) We already tag most of the above, and a router can create its own values based on whether the user wants to ride in the gutter or in the general purpose lane. shoulder=paved seems like an obvious tag for that purpose, and I'm not sure what you mean by a 'bike friendly sidewalk'. Nothing specific, but probably something wider than a regular sidewalk with curb ramps but not a dedicated bike/exercise trail. I was just looking for things to flesh out the example, and did not mean them as a very serious place to start for safety/quality ranking. As this shows, good descriptions, and pictures would be important to get reasonably consistent results from differing users. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging bicycle anti-routes
As with many OSM tags, there are objective items to begin the categorization. The final decision though will be at least partly subjective. Class:bicycle is a good start. Perhaps list specific features as a base for the ranking, then things that would drop that to lower rankings. An example of what I mean for starting values. separate paved bike/general path = +3 road with bike lane = +2 road with bike route= +1 road with a good shoulder / bike friendly sidewalk = 0 ?=-1 ?=-2 Limited access highway = -3 (should normally be no bike access anyhow) Then start to look for other factors that would lower the ranking. Frequent stop signs against the route. -0.2 (what is frequent) Roadside parking -1 (or 1.5) Busy road -0.7 (how to measure) poor surface -0.5 (how to measure) Small or no shoulder -1 User bias from +1 to -1 to adjust for local differences from the suggested standard. Add that up and round to the nearest whole number. Building the above recommendations will take time, and have to be rebalanced so they actually fit most situations. Work out starting recomendations, then tag an area and see how it matches with bikers opinions. Adjust the recommendations and try again, perhaps another area to make sure it fits multiple situations. I think up to about 10 or 15 things to possibly consider would be good. Beyond that it will be too much information and too complicated for the average person. If it takes more than about 20 seconds to decide the value it is probably too complex a system. On Thu, Nov 4, 2010 at 1:11 PM, Toby Murray toby.mur...@gmail.com wrote: Someone in my area decided to try and make a bicycle map. He used this scheme: http://wiki.openstreetmap.org/wiki/Class:bicycle And rendered this map: http://bikemanhattan.info/ Now I know people are going to complain that this is a subjective tag and that it shouldn't be in OSM. And I don't entirely disagree... but oh well. It worked for him and I don't dislike the results he got from it. Toby On Thu, Nov 4, 2010 at 9:31 AM, Leroy E Leonard leeoncand...@gmail.com wrote: In Decatur, Georgia, Bike Decatur, the city government and recreation departments and fellow OSMers are working together to create a bike suitability map with suggested routes in the area. This is a snapshot of the map in progress: https://docs.google.com/leaf?id=0B_hqPUZzUTJMZjQwZmIzYzgtMjM3Yi00YjczLTk0ZjktNjdmZmQ2ODZlYjgyhl=en [ Here's the data rendered in Cycle Map: http://www.openstreetmap.org/?lat=33.7718lon=-84.2935zoom=14layers=C] The next step is tagging tricky intersections and sections of roadway where cyclist should exercise extra caution. Any recommendations for tagging these anti-features? Any feedback or questions on the project in general are welcome. -- Lee ___ 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 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
== Inconsistent State Prefixes == I wish there was a better (simpler) way to consistently tag the state and county shields but I do not have one. I think it needs to be done though. Compared to the rest of the world, I think the US has an extra layer of 50 varying standards to deal with. I would add to Val's e-mail that county roads might need the same US:UT:CR-14 as I believe they are handled differently in some state as well. Also to differentiate them from tags from other parts of the world. -- Dale Puch On Fri, Oct 15, 2010 at 12:47 PM, Val Kartchner val...@gmail.com wrote: On Fri, 2010-10-15 at 12:08 -0400, Phil! Gold wrote: == Hyphens == There's a lot of inconsistency in tagging in road's ref= tags. The main wiki pages (Interstate Highways, United States road tagging) specifically call for using spaces between the network designation and the network number. A lot of people still use dashes for Interstates, because thet's how they're commonly written (and because I-5 is more obvious than I 5, which might be read as 15). At least here in the US, the dash is convention so it should be used in the map. == Inconsistent State Prefixes == This is another very inconsistent area. The main US wiki page (United States road tagging) says to use the state's two-letter postal code (optionally with a US: prefix). In practice, usage varies wildly, generally based on how individual states prefer to represent their routes: in states like Maryland that use their postal code, usage is pretty uniform; in states like Ohio that use a SR prefix, usage is mixed between local customs and the postal code standard. A further complication is the presence of county roads. The wiki doesn't mention any standard for those. From what I've seen, they mostly end up as CR or whatever the local nomenclature is. Should we use the postal code everywhere for nationwide consistency or should we use the prefixes that locals use? If we use postal codes, what should we do about county or town roads? We should find some consistent way to do it such that it is easy for a renderer to parse. Then the renderers will need to be changed to use them. Once this is done, people will be more likely to enter them properly since they will show up in a special way. So, for instance, in Utah the state routes are designated (without abbreviation) State Route 67 (for instance). This is abbreviated as SR-67. However, a sign with this designation is not used very much. The much more commonly used signage is 67 is the state highway shield (a white beehive on a black background). This is how the renderers should put it on the state highways. (Wikipedia does it this way on each page.) I haven't seen any county road signs (on physical roads), but I've heard the renderers will draw the number in a circle. The standard should be something easy to parse. Perhaps, for the above example, it would be US:UT:SR-67. This would allow an easy way to parse which shield to use. For instance, a made-up Canadian route would be CA:BC:12. The colons would designate a field, and a space or dash would indicate a subfield. The renderer could just use all but the last field to figure out which shield to use (US:UT or CA:BC), then use the last subfield of the last field to draw the shield. This would work for an instance I've seen in New Hampshire which would be US:NH:3A. I'm sure that there are some exceptions, to using the last subfield to draw the shield. Let's hear about them. == Semi-Colons == He shows a road that has a ref= of I 88;56. I think it should be completely uncontroversial to say that each part of a semicolon-delimited ref should have the appropriate network information in it. I agree with your solution. Again, the renderer needs to draw the highway shields. If there is no special treatment by the renderer for doing things in the proper way, then it is less likely that things will be tagged correctly. I'm reminded of the truism, What gets rewarded gets repeated. - Val - ___ 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] Troubleshooting rendering problems
It would be nice to have a procedure for finding these problems. Sometimes they only show up at low zoom levels due to the scope of the problem. But some of what I have seen may be due to other tiles not being updated (next to the tile with the changed way) As I understand it some possible problems on area features are: extra items in the relation missing items in the relation/way reversed way (can a relation be reversed as well?) segments in the relation not actually connecting each other I have never managed to track down the offending feature so take this with a grain of salt. Is there an easy way to view the map tiles, and request one be re-rendered? Dale On Thu, Sep 23, 2010 at 2:16 PM, Nathan Edgars II nerou...@gmail.comwrote: On Thu, Sep 23, 2010 at 2:11 PM, Leroy E Leonard leeoncand...@gmail.com wrote: Thanks. So how did you figure that out? I (and probably other folks on the list) would like to be able to troubleshoot this kind of problem in the future. I looked at the way on the border of the solid white and saw what relations it belonged to, then looked for stray members. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Troubleshooting rendering problems
Yep just the sort of tool I was looking for! On Thu, Sep 23, 2010 at 3:44 PM, Frederik Ramm frede...@remote.org wrote: Hi, Dale Puch wrote: It would be nice to have a procedure for finding these problems. Try the OSM inspector's multipolygon view, at http://tools.geofabrik.de/osmi/debug.html (then select multipolygons from the view drop-down - note that only the views with an earth icon are world-wide but multipolygon is one of them). To save you the zooming, here's a permalink: http://tools.geofabrik.de/osmi/debug.html?view=multipolygonlon=-84.29300lat=33.77300zoom=12overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes As you can see, the offending relation is clearly marked in the middle with ring not closed and the non-connected endpoints are painted red. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix Suffix Indication
I basically agree with Mike A couple of links for reading relating to this discussion. (Several are PDF's) http://www.co.larimer.co.us/streets/rules.htm http://www.ltg.gov.vi/GIS_2010/usvi_street_naming_project_guidelines.pdf http://flathead.mt.gov/gis/documents/Conventions.pdf http://www.mlgw.com/images/StreetNamingGuidelines.pdf http://libraries.maine.edu/Spatial/gisweb/spatdb/gis-lis/gi94040.html http://www.cravencounty.com/documents/RoadNamingOrdinance.PDF Reading a few of these... These are guidelines for NEW names, and old existing names can be and are a mess in some places. I do not think there is any sure fire way to deal with the names due to the older ones that did not follow such conventions. Because of this any thing presented must be guidelines, and clearly state that not all roads will clearly fit them. They should probably be based on the newer naming conventions, and anything that does not fit should all be left in the base name. It seems clear that directions do convey meaning such as which part of a long road, and that they are part of the name as much as road or street is. The full name should be broken up into components. Applications using the databse can decide how much and how they will make use of that information. Such as abbreviate, or drop directionals. What locals use can be placed in another tag if it differs from the official name, but should not be the primary name in the database. Local governmental standars do affect how we try to break up the names, but not how locals (as in along that street) use the names. On Mon, Aug 23, 2010 at 3:59 PM, Mike Thompson miketh...@gmail.com wrote: You have caused me to do some real thinking and digging on this subject. I think this debate is good, and will lead to better OSM data in the long run. I think the rules should be replaced with the following guidelines. If the directional is on the street sign, this is a strong indication that it should be part of the name. Pre-directionals are included in at least some street signs in Columbus Ohio, but not in SLC. Note, the size of the font does not mitigate the fact that they are on the signs. If official local government sources use pre-directionals, this is very strong indication that they should be part of the name. The Franklin County Ohio (where Columbus is located) Highway engineer includes directions in some cases on their maps. Note E. North Broadway and W. North Broadway on the following map: http://www.fceo.co.franklin.oh.us/Map-Atlas%20Pages/map_19.PDF, but not all. Note W Broad St in this map from the same source: http://www.fceo.co.franklin.oh.us/Map-Atlas%20Pages/map_27.PDF. Also, the Franklin County Auditor often uses directionals in their property database, although not consistently. If local residents and businesses _ever_ use directionals when talking about a street, this is an indication that it should be part of the name (I think we agree on this one). A test that I have not heard mentioned here is whether the directional appears as part of the building/house number on the sides of buildings (e.g 1705 W). If it does, we know for sure that it is part of the building number, and not the street name and it can safely be removed from the street name. That will hardly every apply. A very good indication that pre-directionals should not be removed from the name tag outside of Utah. A city style address consists of a building number, and a street name (we are not concerned here with city state or zip). If the directional is part of the complete address, it must be either part of the building number, or the street name. If is not on the front of the building with the building number, then it must be part of the street name. Again you are taking that test too literally. Tests are to be taken fairly literally. With these tests in the proposal, a new mapper may easily get the impression that in OSM pre-directionals are almost always to be removed from the name tag. This test will fail in Washington DC and other places where the directionals are really needed. The point should not be just whether directionals are needed, but whether they are regarded by local residents, businesses, and government officials as a part of the name. This should be evidenced by signage, official local government documents, and local usage (again, I think we agree on this final guideline). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix Suffix Indication
Actually I think it is pretty easy, if tedious. Check with the local government office. They have tons of information of interest to OSM. It is a matter of verifying permission to use it, and importing it in some way, or in this case referencing it. On Mon, Aug 23, 2010 at 7:23 PM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: On Mon, 23 Aug 2010, Dale Puch wrote: What locals use can be placed in another tag if it differs from the official name, but should not be the primary name in the database. Local governmental standars do affect how we try to break up the names, but not how locals (as in along that street) use the names. Determining the official name may not always be easy. The only reasonable thing to do is go with how they are signed, and what locals think the official name is. Can we agree that prefixes should probably be separated out if they are hardly ever (I don't want to say never as there are always rare exceptions) included in the street sign in any form? For other cases I think we really need some locals input in how naming is handled in their city. I asked Vid The Kid to join in on the conversation, I think he would provide some valuable feedback. He removed the prefixes in several streets in Columbus, OH. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Can US OSM help with license upgrade? (was: Re: License Upgrade - Stage Two Begins)
And those are the basic assumptions I made as well. The problem is neither of us are lawyers and know what legal risks are involved with those assumption other than stay away from anything not CLEARLY labeled PD On Fri, Aug 20, 2010 at 7:12 PM, Apollinaris Schoell ascho...@gmail.comwrote: On Mon, Aug 16, 2010 at 1:26 PM, Dale Puch dale.p...@gmail.com wrote: A real problem is that the data itself is not properly tagged, or does not explicitly state what if any restrictions are placed on it. When it is not perfectly clear is when non-lawyers like us are putting themselves and OSM in possible trouble. if it's not tagged we must assume it is under copyright and not PD A few examples: The web site has copyright notices on it, but the shape file data for access is blank but asks for attribution... An e-mail response regarding this is that we can use it with attribution. What satisfies the attribution, and is that e-mail valid permission for the data use? I think email has been used in many cases in court, so let's assume good faith if there is an email. Even if you have a written letter you will not do research to prove that the signature is real. that the letter is from the company and the signer is allowed to sign such a permit Some place charge a fee to get the data, but is it then free to then copy and reuse? as long as the fee is cost of distribution then data itself may still be PD Official state clearinghouses (usually a university) will sometimes edit the shape files to include copyright, even though the source data was specifically not. Free to get and use for personal use is not equal to public domain. Exactly, this is no longer PD and you need the original source. But it will be impossible for anyone to prove that you took their non free data. they can add easter eggs so better to stay away from using such data The problem here is that that the clearinghouse is the OFFICIAL distribution point, the original agency points you to that site for any downloads. Even if the original agency specifically gives permission, the data is labeled as copyrighted by the clearinghouse. Thus the US OSM determining the legalities for OSM as a group in the US seems like a good idea. At the very least having a layer draw up some rules and guidelines for us to follow would be a huge benefit to making more data available for use. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Tue, Aug 17, 2010 at 12:19 AM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: On Mon, 16 Aug 2010, Dale Puch wrote: The directional prefix/suffix absolutely should not be dropped from any streets. Even ones that are simple straight lines that change N/S or E/W at a point along it. Treat them as 2 different streets. 1) Why? 2) Do you live in an area that uses directional prefixes that way? Because your losing information. If your separating the elements to different tags... if truly not part of the name, it can be used for part of the address instead of street. Is it really not part of the street name, what are the rules you use to determine it is only part of the address? -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
Well, personally there is what is, what should be, and what is practical. The directional prefix/suffix absolutely should not be dropped from any streets. Even ones that are simple straight lines that change N/S or E/W at a point along it. Treat them as 2 different streets. What to abbreviate... nothing in the database. Let the renders ect. decide what to or not to. The database would be much better with the address broken into well defined parts. Ideally without the current name tag, and always build the full name. I doubt this would work well for data entry by OSM users though. Unabreviated directional prefix/suffix, type, and the base/remaining name might be palatable though. Anything that will not fit nicely into the extra tags just goes in the base name tag. In fact, keep using the current name tag. Dale On Sat, Aug 14, 2010 at 12:07 AM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: On Fri, 13 Aug 2010, Steven Johnson wrote: If you want to see the mother of all street naming trainwrecks, have a look at Hickory, NC. Story goes that sometime back in the '30's, the city fathers/mothers thought they would rationalize street naming. But what makes sense on gridded streets makes an *awful* mnemonic device for wayfinding, especially in the hilly, western piedmont of NC. You also have some really perverse examples of streetnaming, like 19th Ave Pl NW. Thanks for the other data point. In case I didn't make it already clear in my other emails, what I am saying is that maybe always displaying the directionals is not always the best way to present them. I do not know what the correct solution is. However, I am not advocating the complete suppression except in limited cases. For example, when the directional is more of a positive/negative for an address than specifying a region of the city, such as the case in Salt Lake City. The decision to suppress directionals in this limited case should be evaluated on a city by city bases and by those who are familiar with the area. Rather than look to paper maps and Google for how they map it, it may be more useful to look at how local E911 services and USPS treat these addresses. That is not going to help, what is at issue here (at least for me) is what should be displayed as part of the street name of a map. Not what goes into the address. There are times when a street type (e.g. Ave, St, Ln, Pl) is part of the name (e.g. 19th Ave Pl NW, where Ave is part of the street name) and times when the directional prefix/suffix (e.g. N, S, E W) are part of the street name (e.g. North Temple). I think only local knowledge is the way to resolve these issues. Yes local knowledge is the only way to resolve it. ___ 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] United States Roadway Classification Guidelines
On Wed, Jul 28, 2010 at 11:01 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: There's no observation that will tell you whether a road is primary or secondary. Agreed. There is no observation that will tell you whether a road is more important than another road that is not where you are. But you can identify physical characteristics. A lot of these observations will lead to a coherent whole. Yep that is the problem. And all the discussion and many wiki pages are about trying to come up with a consistent guideline for turning those observations into consistant and useful OSM tags. There are two extremes of OSM that are fighting each other because lack of consensus and organization. We say both tag as you want, and follow what has been agreed on in the wiki (which is constantly changing). Existing DOT data is also an observation to add to the mix in deciding how to tag something. Don't dismiss it just because there are exceptions to the way someone else tags. Ramblings and grandiose goals: The goal of describing what is on the ground is great, but to what end. The tags will be plentiful but perhaps useless if not designed for specific uses! The primary use will be visual maps. Any secondary usage would also need to be considered. Layout a tagging plan for these uses and tag for that, but make sure it is still flexible for future changes. Don't force using a tag because it displays nicely on a map that way, but do use a tag because it is the common (thought out and planned) tagging scheme that the render's happen to implement. Render's should be the visual representation of what the wiki describes. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Community Involvement
No not all states, or counties have the same data policies. Generally they are, but Rarely clearly state so. All have to be asked individually if you want to be on the safe side. Specifically I think Michigan state data is NOT public domain. Others charge for the getting the data, but are open for copy/use with attribution. I have also run into the original data being open, but not directly available and the data clearinghouse then puts their own restrictions on the use. I'm not sure that is actually valid legally... Anyhow, yea it is a mess. And if you do get a response that the data is public domain, or requires attribution... The best I have come up with was to post the info to the wiki including the e-mail response in the discussion page. -- Dale Puch On Mon, Jul 19, 2010 at 5:16 PM, Toby Murray toby.mur...@gmail.com wrote: My thoughts about OSM US: I don't know if you will have resources for this but it would be nice to have some legally authoritative information when dealing with potential government data sources. Since copyright laws vary by country this seems like a good thing for a national chapter to deal with. Maybe even at the state level. I found out (by asking) that the Kansas DoT considers all the maps on their website to be in the public domain so they are all usable in OSM. Is this the case in other states? I'm not suggesting that OSM US start trying to contact state government divisions in all 50 states but perhaps there could be some suggestions on how to initiate contact with a government agency. What about the impact of the Santa Clara county lawsuit back in 2009? Are there any parts of that decision that could be used as a precedent in other jurisdictions? My county is pretty awesome in that they gave me permission to use their 6 aerial imagery for tracing but when I asked the county next door, I was told that they charge for all their GIS data, end of story. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Uploading all Post Office Drop Box locations in the US
http://www.usps.com/foia/ Under the owned/leased properties data: *The information contained in the report is provided by the United States Postal Service under the Freedom of information Act and should not be redistributed or resold.* Not sure if they can hold people to that or they just want to try to keep people from distributing the information. I don't see anything about the drop boxes though. Guidelines for Copyrighted Materials and the FOIA http://www.justice.gov/oip/foia_updates/Vol_IV_4/page3.htm Perhaps someone can make use of some of that info. On Thu, Jun 10, 2010 at 7:03 PM, SteveC st...@asklater.com wrote: so just do another FOIA request? On Jun 10, 2010, at 11:48 AM, Ian Dees wrote: I would say that at least 1/3 of the post office drop boxes nationwide have been removed or pulled out of service since this data has been released, making an import of the data both inaccurate (due to geocoding) and old. On Thu, Jun 10, 2010 at 1:37 PM, Kirk Ireson palmerstat...@gmail.com wrote: I was adding a couple local USPS Post Office drop box locations using Potlatch when I wondered if there was a public list of locations I could upload. I did find that there was a release of 2005 locations that was released under the Freedom of Information Act. There are 20 Excel files ranging from 14,000 to 65,000 lines in length each and it looks like they do have all the locations. I thought it would be a good project for me to extract/clean up the data and geocode it for upload (only addresses are given in the files) and so would like to first seek feedback from the community before proceeding especially with regards to licensing, tagging and geocoding. LICENSING: The data comes from here: http://www.prc.gov/docs/53/53396/DFC-LR-2-R200-6.exe The best information in regards to its release I can find is from here: http://66.208.7.72/(S(tgqmwqywriczne55l1bjqtnu))/Docs/53/53359/Testimony_Errata.pdfhttp://66.208.7.72/%28S%28tgqmwqywriczne55l1bjqtnu%29%29/Docs/53/53359/Testimony_Errata.pdf Which is erratum of a Postal Rate Commission Docket, which states In 2002, I submitted a Freedom of Information Act (FOIA) request to the Postal Service for an electronic copy of pertinent information from the CBMS database. The Postal Service declared that releasing information on locations and posted collection times of collection boxes would pose a security risk. I filed a lawsuit, and in March 2005, a federal judge ruled in my favor and ordered the Postal Service to disclose the data. In September 2005, the Postal Service provided (and then is cut off) See also here: http://www.postalnewsblog.com/2007/10/16/usps-loses-appeal-of-foia-case/ -Is this compatible licensing? -What kind of attribution is required? TAGGING: Included in the released files is the pickup times of the boxes. -Should this info be included as a tag? How? -Also, what kind of tag should I use to denote this is a bulk upload of locations, or should I just create a dedicated user account for the import? -How do I prevent duplicating existing positions already uploaded by users? GEOCODING: -Can anyone recommend a geocoding service (that is, translating an address to latitude/longitude) preferably free or very cheap. Only one I've found is http://geocoder.us (since I can't use Yahoo's or Google's without using them on one of their maps), but I can only send one request per 15 seconds and so it will take weeks (since I don't want to pay hundreds of dollars). -Additionally, should I also cross post these questions to the 'imports' mailing list? Cheers and thanks for any and all help, ~Kirk Ireson -- View this message in context: http://gis.638310.n2.nabble.com/Uploading-all-Post-Office-Drop-Box-locations-in-the-US-tp5164668p5164668.html Sent from the USA mailing list archive at Nabble.com. ___ 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 have fun, Steve Coast / stevecoast.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Openstreetmap write up on ars-technica.com
Just a FYI if you wanted to read it. It is always good to see some publicity. http://arstechnica.com/open-source/news/2010/06/crowd-sourced-world-map.ars -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Do Old Olive Street Rd and Old Olive St Rd have overlapping street numbers? No, then the street number distinguishes location. If Yes then do the rest of the address match up? No this time then the rest of the address distinguishes location. If Yes again, someone messed up the street naming. Unless someone messed up, either one should work. If it is a continous road, I would standardize on one name. Personally I would use Old Olive Street Rd As far as searches go, the engine just needs to be smart enough to try matching the various full words and abbreviations, and offer a choice if more than one results turn up. Dale On Mon, May 17, 2010 at 8:29 PM, Nathan Oliver oliver.nat...@gmail.comwrote: I happen to know the answer to this one. I'll save Brett the trouble of replying again, and point you to an earlier explanation in this thread. (Though being so long, I don't blame you for not seeing it the first time around.) http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003087.html It seems really odd to me, too, but it's not the first time customs have developed in odd ways... Nathan Oliver On 5/17/2010 7:01 PM, Nathan Edgars II wrote: Dale Puch wrote: On Mon, May 17, 2010 at 4:44 PM, Nathan Edgars II neroute2 at gmail.comwrote: Lord-Castillo, Brett wrote: But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). So if Old Olive Street Rd and Old Olive St Rd are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be official, but both are unambiguous and correct for all practical purposes)? If Old Olive Street Rd and Old Olive St Rd are one road, ie. connected and not and a corner. Then things that may explain it are different addresses where they intersect, or if they are in different jurisdictions. Like where two cities meet. But if the addressing continues between the different names, then it seem one sign is wrong. I personally think Old Olive Street Rd should be used, and only cardinal direction prefix and type suffix abbreviated. The rest being the core name. I'm not sure what you mean - if you tell someone I live at 50 Old Olive Street Rd, how is that any different from I live at 50 Old Olive St Rd? (Obviously one would need to specify which city the address is in, if the official name changes at the city line. But, without the city name, neither of those statements, even written, would be truly unambiguous, since the reader can't assume the chosen Street or St is identical to the official usage. In fact, if we do name these segments differently, it could cause more confusion, since someone typing one might be taken to the official match when they wanted the other one and didn't realize they were officially different.) As for abbreviations, there's no consistent way to abbreviate. Around here, you'll see Parkway, Pkwy, Pky, and Py all used for the same road. And directional prefixes are part of the address, appearing above the block number in a separate square on street signs. ___ 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] Street Naming Conventions
If Old Olive Street Rd and Old Olive St Rd are one road, ie. connected and not and a corner. Then things that may explain it are different addresses where they intersect, or if they are in different jurisdictions. Like where two cities meet. But if the addressing continues between the different names, then it seem one sign is wrong. I personally think Old Olive Street Rd should be used, and only cardinal direction prefix and type suffix abbreviated. The rest being the core name. That said, someone really liked to use Olive in the naming Dale On Mon, May 17, 2010 at 4:44 PM, Nathan Edgars II nerou...@gmail.comwrote: Lord-Castillo, Brett wrote: But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). So if Old Olive Street Rd and Old Olive St Rd are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be official, but both are unambiguous and correct for all practical purposes)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Gov't/military firing ranges --- not sport
I think I see your concern. I think Military should be tagged as Richard suggested, and the civilian ranges, including police should still be sport:shooting both per the wiki. Police use public ranges sometiems (or are open to public use) and if not they are reasonable contained and controlled to police only access anyhow. Would you be concerned about highway:raceway not conveying the danger of the area? You could be killed wandering around the wrong parts of either one. No need to over think things, and you can't eliminate the need for common sense with better tagging. -- Dale Puch On Sat, May 8, 2010 at 1:16 PM, David Carmean d...@halibut.com wrote: On Sat, May 08, 2010 at 10:39:37AM -0400, Richard Welty wrote: On 5/8/10 9:40 AM, David Carmean wrote: I'm reluctant to tag civil/military gov't firing ranges as sport. I'd consider them more as hazardous areas to mark/avoid, but I don't know how to tag them as such. Ideas? landuse=military military=danger_area and landuse=military military=range are both documented in the wiki: http://wiki.openstreetmap.org/wiki/Map_Features#Military i should think you would use danger_area even for inactive ranges, due to the potential for unexploded munitions. Ah, ok; I think I made my question too generic; I actually want to map civil government (i.e. police) ranges 90% of the time. ___ 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] USGS has no problem using information from copyrighted maps
It will probably take some digging to find out the full story, and it will probably differ from state to state. But it seems that around 1995-2005 time range federal, state and local governments started to share GIS data. As they did this they also changed their copyright and access policies due to the sharing. To make matters worse, very few clearly state any copyright or restrictions, even though there is a specific field in the meta-data. While I do not know for sure, my guess is that the original map was indeed copyrighted, but at a later date the map, or data was shared with other agencies and the result was no longer copyrighted. It would be really nice to have the copyright/usability status of various data sets published by the various agencies. Dale On Thu, Apr 8, 2010 at 7:18 AM, Nathan Edgars II nerou...@gmail.com wrote: First, I'm not trying to start an argument or even a civilized discussion about our policies in this matter. I just found this interesting. http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1196597 is Rosslyn Station, a former railway station in Pennsylvania. The source cited for the feature is a map created by the Pennsylvania Department of Transportation: ftp://ftp.dot.state.pa.us/public/pdf/BPR_PDF_FILES/Maps/Type_10_GHS_Historical_Scans/Allegheny_1976_Sheet_1.pdf This map, from which USGS got the name and location, is labeled Copyright 1977 Commonwealth of Pennsylvania. (Yes, our GNIS import includes this feature.) The USGS doesn't seem to consider this information copyrightable: http://www.usgs.gov/usgs-manual/1100/1100-6.html prescribes a notice to appear when copyrighted materials are used in an information product, which I don't see with the GNIS, and http://geonames.usgs.gov/domestic/metadata.htm#getacopy.0 says that there are no access or use constraints. ___ 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] USGS has no problem using information from copyrighted maps
For reference, http://www.fgdc.gov/library/factsheets/documents/datashare.pdf There are exceptions, but from what I have seen this policy seems to be the basis of the government opening up GIS data. Dale On Thu, Apr 8, 2010 at 3:02 PM, Dale Puch dale.p...@gmail.com wrote: It will probably take some digging to find out the full story, and it will probably differ from state to state. But it seems that around 1995-2005 time range federal, state and local governments started to share GIS data. As they did this they also changed their copyright and access policies due to the sharing. To make matters worse, very few clearly state any copyright or restrictions, even though there is a specific field in the meta-data. While I do not know for sure, my guess is that the original map was indeed copyrighted, but at a later date the map, or data was shared with other agencies and the result was no longer copyrighted. It would be really nice to have the copyright/usability status of various data sets published by the various agencies. Dale On Thu, Apr 8, 2010 at 7:18 AM, Nathan Edgars II nerou...@gmail.comwrote: First, I'm not trying to start an argument or even a civilized discussion about our policies in this matter. I just found this interesting. http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1196597 is Rosslyn Station, a former railway station in Pennsylvania. The source cited for the feature is a map created by the Pennsylvania Department of Transportation: ftp://ftp.dot.state.pa.us/public/pdf/BPR_PDF_FILES/Maps/Type_10_GHS_Historical_Scans/Allegheny_1976_Sheet_1.pdf This map, from which USGS got the name and location, is labeled Copyright 1977 Commonwealth of Pennsylvania. (Yes, our GNIS import includes this feature.) The USGS doesn't seem to consider this information copyrightable: http://www.usgs.gov/usgs-manual/1100/1100-6.html prescribes a notice to appear when copyrighted materials are used in an information product, which I don't see with the GNIS, and http://geonames.usgs.gov/domestic/metadata.htm#getacopy.0 says that there are no access or use constraints. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Using a bot for specific well know Suffix abbreviations only should be reasonably safe. IE never change ST to street if it is a prefix sort of rules. Dale On Thu, Apr 8, 2010 at 12:23 PM, Richard Welty rwe...@averillpark.netwrote: On 4/8/10 9:48 AM, Lord-Castillo, Brett wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. the thing i think most of us are arguing for is in cases where we know that ST == Street, Rd == Road, Blvd == Boulevard, we should be storing the full string, and treating abbreviations as a rendering problem. how we get there is an implementation issue to be resolved. right now, i fix them by hand when editing in josm because the josm validator whines about it. richard ___ 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] Street Naming Conventions
Perhaps we should take a look at what a bot would match. Run a bot that finds and counts the various matches and outputs a report only. pre, mid and suffix counts the abbreviations. and what the bot would expand each abbreviation to. Abbreviations in the middle should be located, but probably not changed by the bot. The pre and suffix ones should be pretty safe. Then start to decide which would be safe to run based on the results. If this can be done by state or perhaps even county all the better to minimize issues with local standards. Anything that might be questionable we would want to manually look at the current names and results. Having a link to a potlatch view or josm shortcut would be all the better. Let the bot run on the safer choices, the rest we would have a list to manually check and edit if needed. Similar to what was done with motorway links. Yes there will be mistakes, but stuff like having two streets with 'saint louis street' and 'st louis street' names is only going to be fixable by locals IMO Then again how much different is that from two streets with the same name in adjacent towns? Unless the city and zip are the same, what will it really matter? Dale On Thu, Apr 8, 2010 at 4:35 PM, Richard Welty rwe...@averillpark.netwrote: all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale On Thu, Apr 8, 2010 at 11:32 PM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ 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] Street Naming Conventions
Err, well you brought them up ;) But yes I guess this would largly be directed towards the bot master. E Ave example the bot needs to not change E to east despite it being the first item. The logic would be that there is no base name if E is changed to east ans Ave changed to Avenue. Deciding the suffix is the one to change and leaving the E as the base name is a little harder to be sure about when programming the bot. The southbay example... Well were talking about expanding abbreviations. So as long as we don't remove spaces when doing so there should not be any problems. Southbay has no abbreviations, and S Bay would be expanded to South Bay While the names are confusing, they would remain correct. Dale On Fri, Apr 9, 2010 at 12:08 AM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ 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] Street Naming Conventions
It would probably be best to have both the 'as displayed' name, and 'as spoken' in the tags. Anything else you have to make assumptions that may or may not be right. If both are not stored, the next best alternative seems to be having the full spoken name in the tags, but have seprate prefix(directional), name and suffix fields. That way the prefix and suffix can be abbreviated while leaving the actual name alone where the odd ones might be matched to an abbreviation. This wold not cover things like the saint prefix to St. abbreviation without adding a 4th field directional, prefix, name, suffix Personally I like the 3 field, or event the 4 field storage of the name. Yes that means there is not a single field that has the full name, but I do not think a lookup and concat of 4 fields vs 1 field is much different in an indexed database. Perhaps a DB admin can shed some light on the best approach from a design and system resources standpoint. This may be a problem for apps, but if it is the best way to manage the data, the apps just need to be changed. And it would not be that hard to make the programming change if I can figure out how to do it with my limited knowledge. Some of the examples comma separated into the 4 field format: South, ,1000 East, Street ,State, Park, Street ,Saint, Tropez, Street As per the wiki, the translation to abbreviated names is a program or renderer issue, but using the USPS (for the US) as a guideline/reference seems like a good idea. The other two problems, are converting the existing names and getting everyone to input the fields correctly. A bot is always an issue. There are ways to minimize the problems though. Start with the easy ones to process automatically. Probably referencing external data to assure correct conversions by checking if similar names are in the same geographic region, and skip any that might get mixed up. Flag those for later bots, or manual correction. Dale On Wed, Apr 7, 2010 at 2:12 PM, Mike Thompson miketh...@gmail.com wrote: I have worked with these issues for a number of years in my professional life. We have found that it is better to spell out street names. As Matthias pointed out, it is far easier to convert a named that is spelled out to one that is abbreviated than the other way around. I have seen far too many problems with going the other way. Cases where Dr was expanded to Doctor, St was expanded to Saint, etc (and vise versa) when that was not the intention. By spelling out the names we make it easier for the application consuming the data (e.g. a renderer) to make its own decision as to whether to abbreviate or not. If we use abbreviations, we lock the application into using abbreviations (and using the same abbreviations), or at the very least, make it difficult to do otherwise. Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. Mike On Wed, Apr 7, 2010 at 11:27 AM, am12 a...@bolis.com wrote: What do people think? It is easy (I think) to know what St, Ave, and Blvd mean at the end of the name. The rest of them aren't always clear. I recently had to figure out what a Lp was (Loop - this one was new to me). I used to live on Southbay Drive. I would get mail addressed as South Bay Drive, even though there were no north/south address prefixes used anywhere nearby. The strangest was when I would get mail addressed as S Bay Drive. Fortunately there was no Bay Drive in my zipcode. - Alan ___ 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] Whole-US Garmin Map update - 19-03-2010
Drivers basically. I have seen people (end users) try to add SDHC to older palms by modifying or using a newer driver file. Windows moble based devices it is even easier to swap out some DLL's and get SDHC compatibility. Dale On Mon, Mar 22, 2010 at 10:55 PM, Dave Hansen d...@sr71.net wrote: On Mon, 2010-03-22 at 22:46 -0400, Bill Ricker wrote: So do all SD-cable Garmins handle huge map files equally well or not ? I think they should. My 60csx didn't have SDHC support when I bought it, but it got magically added in a firmware update. I'm still not sure how they did that. -- Dave ___ 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] UX Review
Great idea for do user testing! My thoughts: - For new users start with the what brought you.. poll, then from that build a few tests and get volunteers to try some specific tasks. The idea of a few users doing specific tasks to look for the really glaring stuff sounds good. - start small and build from those findings. Only go larger if the small tests aren't productive say at least 10 hot items. - Get screen casts with voice inputs on what they are trying to do and why. - do not limit it to the new users, but the user levels should be different studies. - I see no reason why this could not be applied to potlatch, JOSM, merkator (any other OSM software) and the wiki as well. Even to getting maps on a garmin GPS or what ever else new users might have as reasons for signing up. A side item, where making tasks easier is problematic or fails. Do video tutorials with a transcript or written instructions to go with it. -- Dale Puch On Tue, Mar 9, 2010 at 9:36 AM, Ian Dees ian.d...@gmail.com wrote: On Tue, Mar 9, 2010 at 8:02 AM, SteveC st...@asklater.com wrote: * Once in some very small sample size (perhaps between 1 in 1,000 and 1 in 10,000 signups) a popup appears * The popup says something like Hi! We'd really like to know why you came to OSM and they say simply why. This is open ended on purpose so we catch as many things as we can, not just what we're looking for, but things we won't expect. * They're offered to record a short (10 minute max) screencast of them trying to achieve whatever it is (like look at a map, find OSMers, add a PoI and so on) * That screencast is analyzed in aggregate with many others by Bolt | Peters with all their expertise in doing this stuff, and they come back with a set of findings. Won't this skew our answers a little bit? Users will have to download or install some sort of screen capturing application and answer this question. If I were a novice OSM user and saw this request *and* had to figure out Potlatch or JOSM, I would be even more inclined to back out of fixing the location of the ice cream stand. What should our goals be? (General UX? How good/bad signup is? How good/bad editing is? How is it finding info?) How often should we ask a signup for feedback? (the more the better but we can only look at so many) How can we include more crowd source feedback? (I think of asking random signups for feedback as crowdsourcing it) What else should we think about? I think editing of various kinds should be looked at: anywhere from simple POI adding/changing (how do they figure out how to describe the POI?) to adding/changing a road network (how do they decide what kind of road it is?). Thanks for getting this rolling Steve, I think it'll help! -Ian ___ 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] script for adding layer=1 to bridges
Looking at http://wiki.openstreetmap.org/wiki/Layer My take is that the open to the air surface is layer 0 Ground or water. I'm not sure why it is limited to -5 to 5 instead of -9 to 9... So a bridge over a river or dug ditch is layer 1, and the water would be 0 A road over a covered waterway tunnel is layer 0 and the water -1 A bridge over a canyon is layer 1 + numbers are elevated, 0 is the surface, and - is below ground I feel a script applying layer=1 to any bridge without a layer tag should be ok IF it also checks for bridges that cross it and increment those layer numbers. -- Dale Puch On Thu, Jan 28, 2010 at 3:29 PM, Anthony o...@inbox.org wrote: On Thu, Jan 28, 2010 at 2:34 PM, dion_d...@comcast.net wrote: Maybe I should rephrase my question: is there any harm in adding a layer=1 tag to something that is already tagged bridge=yes? In some cases, yes. No layer tag implies layer=0. For example (and it's only a single example which came to mind), if there are two bridges which cross each other, one has layer=1, and the other has no layer tag, then adding layer=1 to one bridge will break things. Would things be worse after doing this? I submit that the maps would look the same or better in most cases. I don't think that the same or better in most cases is sufficient to justify automated edits. ___ 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] What's causing rendering artifacts in the Southeast?
It sounds like t...@home needs to trim data at the tile border, and then close open ways along the border of the tile... Just my uneducated opinion. Dale On Thu, Nov 26, 2009 at 7:31 PM, David ``Smith'' vidthe...@gmail.comwrote: On Wed, Nov 25, 2009 at 4:13 PM, Dale Puch dale.p...@gmail.com wrote: Oops I spoke too soon. There is a relation. http://www.openstreetmap.org/browse/relation/304245 I still think this is the probable source of the problem though. Perhaps someone with more experience with relations could take a look? I believe the problem is in how ti...@home works. Just enough data (in theory) is downloaded to the client to render one tile at zoom 12 (and all the equivalent tiles at lower zoom levels) and then Osmarender renders the map tiles. I believe the problem is that when some members of a multipolygon intersect this tile and some don't, only those members are downloaded. Without also downloading every other member in the relation, most computer rendering algorithms will fail to draw the feature correctly, because only part of the polygon is loaded. On a related note: when a member of a multipolygon relation also represents a different feature (such as a road) sometimes the tags of that feature are treated as if they apply to the whole relation in Osmarender. I've been meaning to file a trac ticket about that one... -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What's causing rendering artifacts in the Southeast?
On Wed, Nov 25, 2009 at 3:01 PM, Leroy E Leonard leeoncand...@gmail.comwrote: They seem to be related to water ways. They're more evident in Osmarender and Cycle Map. Here's an example in Virginia: http://www.openstreetmap.org/?lat=36.7445lon=-80.9081zoom=14layers=0B00FTF I'd like to fix them as I come across them, but don't know what to do. -- Lee ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us I'm no expert, but what I can see is that mapnik renders it right and osmrender is wrong. Opening small sections of that area in josm (shading areas) also seems to show it wrong until you download the rest of the ways that make up the riverbank. My guess is a missing relations for the riverbanks. Osmrender and josm treat them as open water shorelines. Josm realizes what is the deal when you have more data. Mapnik seems to deal with it seemlessly. -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What's causing rendering artifacts in the Southeast?
On Wed, Nov 25, 2009 at 4:02 PM, Dale Puch dale.p...@gmail.com wrote: On Wed, Nov 25, 2009 at 3:01 PM, Leroy E Leonard leeoncand...@gmail.comwrote: They seem to be related to water ways. They're more evident in Osmarender and Cycle Map. Here's an example in Virginia: http://www.openstreetmap.org/?lat=36.7445lon=-80.9081zoom=14layers=0B00FTF I'd like to fix them as I come across them, but don't know what to do. -- Lee ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us I'm no expert, but what I can see is that mapnik renders it right and osmrender is wrong. Opening small sections of that area in josm (shading areas) also seems to show it wrong until you download the rest of the ways that make up the riverbank. My guess is a missing relations for the riverbanks. Osmrender and josm treat them as open water shorelines. Josm realizes what is the deal when you have more data. Mapnik seems to deal with it seemlessly. -- Dale Puch Oops I spoke too soon. There is a relation. http://www.openstreetmap.org/browse/relation/304245 I still think this is the probable source of the problem though. Perhaps someone with more experience with relations could take a look? -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
