Re: [Talk-us] Schizophrenic highway
At 2012-09-15 16:05, Greg Troxel wrote: Charlotte Wolter techl...@techlady.com writes: I'm working on US 50 near Trenton, Ill. Here's the location: http://www.openstreetmap.org/edit?lat=38.61248lon=-89.68529zoom=16 It looks like, at one point there were plans to turn this into a motorway. In two spots in a 25-mile stretch, intersections have been turned into cloverleafs and the highway divided. In other locations, roads that used to intersect US 50 have been turned into overpasses. There are even a couple of bridges for a second lane but no evidence of any construction work actually to build that lane. The vast majority of the highway is still two-lane blacktop. So how does one tag this, as a primary road that just has a couple of cloverleafs? My take is: motorway: truly meets interstate specs for extended periods - multi lane, no at-grade intersections. I would not tag something as motorway when it's only sometimes motorway unless it's ~10 miles long. US101 near Ventura, CA, goes back and forth among freeway/primary/trunk over relatively short stretches. There are, however, Begin Freeway and End Freeway signs that tell you exactly which sections are motorway. This might be a DOT requirement. SR-1 south of Oxnard is similar. Here's the location of such a sign going northbound: 34.112471°, -119.081681° -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Kern County Import Cleanup
At 2012-07-29 00:30, Paul Norman wrote: While doing this cleanup I would suggest removing attribution, description, kern:Comb_Zn, kern:Zn_Cd1 and setting source=Kern_County_GIS There might be some objects that have been edited, so you'll want to add ;Kern_County_GIS if there is an existing source tag. Are they all http://www.co.kern.ca.us/gis/Files/CountyZoning.zip;, or were there multiple types of data involved? Maybe append the year and month of the file that was imported to the value, too (e.g. Kern_County_GIS_Zones_200810). I'm all for shortening/abbreviating values that are not meant to be rendered (well, I'd be ok with some abbreviation in names, too, but that's a different issue :) ). In particular, it seems a needless waste of space to have these long descriptive source values repeated on every object of an import. It makes more sense to me to document a source on the wiki page for the source tag and use a reasonable abbreviation for it. For example, in one particular excerpt (of source values with commas), the source value EarthScope (http://www.earthscope.org),International Solar Information Solutions (http://www.isi-solutions.org),OpenTopography (http://www.opentopography.org) appears on at least 4000 objects instead of something more reasonable like EarthScope;ISIS;OpenTopo. Defining source values in the wiki would also give one a chance to document details, like the date of the data, research on copyright status, etc. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Kern County Import Cleanup
At 2012-07-29 01:04, Toby Murray wrote: And then we end up with things that are off by 15-20 meters and look crappy: http://www.openstreetmap.org/?lat=34.95455lon=-118.16858zoom=16layers=M It looks like the landuses are shifted by about 28m at 126 degrees from Bing z19 dated 05/08/2010-08/31/2010, but I don't have a ref for the accuracy of Bing exactly there. In this area: http://www.openstreetmap.org/?lat=35.04427lon=-118.163429zoom=18layers=M south of Mojave airport, the landuses are shifted about 8m at 80 degrees. They also appear rotated very slightly - maybe -1 degree. This is relative to Bing z19 5/7/2010-06/21/2010. FAA runway coordinates at MHV show that the imagery is shifted less than 1m from reality. At the interface between the two sets of imagery (around 35.0024 lat), there is a shift of 0-2m between them. Also, my and other GPX tracks along SR-14 also suggest the imagery is accurate. So, it's not clear why some of the landuses are shifted by so much, while others are not. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
At 2012-07-28 00:33, Toby Murray wrote: What do you think about adding a couple of TIGER tags to be silently dropped? ... tiger:separated tiger:upload_uuid +1 tiger:separated I never knew what it was supposed to mean. If it was (as its name suggests) to indicate a physical separation between roadways in each direction, it's almost never accurate for that purpose, IME. Even if it once was, that's probably the most commonly changed feature of a road, usually by building of raised planted center dividers.[0] UUID +1 tiger:tlid At one point, I tried to use TLID for something, only to discover that there was a bug in the import that ended up putting the wrong values on some ways. This was confirmed by Dave Hansen at the time I brought it up. Dump it. This brings up another issue[1]. tiger:county I'm not sure this has been maintained well. I've seen roads combined to cross county lines. People have worked hard on better county polygons, which we should use. Dump it. tiger:cfcc tiger:source +1 zip code Often inaccurate, and subject to the same lack of maintenance problem. I found it useful for a while to get me in the right area when consulting a zip-to-assessor's book lookup I created for San Bernardino County, but I have a better solution now. Dump it. Some people have been removing some TIGER tags already for a while. My only concern would be that, if all the TIGER tags are removed from an object, we should add TIGER05 to the source tag, so as not to completely lose attribution. [0] When micro-mapping planted raised medians and grass strips along sidewalks, what are the correct tags to use? They're not gardens, forests, or parks, though they have grass and trees. [1] When combining ways in JOSM (at least), values for tiger:* tags are combined with : (colon) as a delimiter, instead of ; (semi-colon). Why, and should this be changed? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Tools to help find areas corrupted by redaction
For those of you that have been doing cleanup after the redaction, are you noticing anything in particular that could benefit from automated help? For example, in an area I looked at yesterday, I saw a bunch of sawtooth formations, where a way would depart drastically from the true path of the road, then come back to a node on the road, then a node away again, etc. These nodes that were off the road were presumably those that had been moved to the correct alignment by a non-agreeing user, and were therefore moved back to their wrong locations by the bot. Example: http://www.openstreetmap.org/?lat=33.744884lon=-117.608049zoom=18layers=M I think these could be identified programmatically in a similar way as a smoothing algorithm: Calc the bearing b12 from p1 to p2, b23 from p2 to p3, and b24 from p2 to p4. If b12 is closer to b24 than b23 by a specified amount, the line is smoother without p3 in it, and is possibly corrupt. A little mathematical creativity can avoid having to calc the actual bearings with arctan on every point, since it's really the relative ratios that matter and not the actual values of the angles themselves. Another thing is that these sawtooth ways tend to cross other ways without intersection, so this is a good indicator, too. Lastly, I'm noticing orphan nodes in areas that need work. These would make good layer(s) in the Geofabrik OSM Inspector. Other ideas? -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Highway ref again.
At 2012-07-26 18:48, Clay Smalley wrote: On Thu, Jul 26, 2012 at 5:49 PM, Apollinaris Schöll ascho...@gmail.com wrote: - multiple refs in tag with a semicolon: Many of them had been entered not too long ago and are clearly not a damage from the redaction. Wasn't the consensus to use relations? In the past I have only used the ref of the most important route on the way itself. This is what is rendered on all maps. secondary routes are only in the relation in case of overlaps. What if they're equally important and recognized (like Interstate 80/90 through Ohio and Indiana, or US 1/9 in New Jersey)? The consumers should not assume anything from the order. Personally, I enter them in alphanumeric order (I think - its been a while). - state routes. In the past most states have been mapped with state number, now many refs have been changed to SR number. According to official documents in California SR is correct. road signs are mixed in California.Most common is number only but SR or state highway ore state route is possible too. BUT we have used the state number for so long and acrossmany states. should we really change? Generally, the state abbreviation is correct (except in cases like Texas with FM and Loop and Spur routes). The use of SR and SH for state highways was mainly (unnecessarily) brought on by NE2. I guess both are correct, but the former is more descriptive and uniform. I support using the state abbrev, as this was the way that seemed to be favored in the documentation years ago, and doesn't require another tag (which *state*?) to disambiguate. Alternatively, moving the prefix to the network tag is OK, too: ref=I 80;US 101;CA 62 becomes ref=80;101;62 + network=US:I;US;US:CA Once editors do a better job of creating those relations and keeping them whole, and consumers correctly handle them, I'm ok with moving the tags to relations. At that point, it would make sense to move all the tags at once. Having them in both places doesn't seem all that maintainable. I also use: ref=FH nn - USFS Forest Highway ref=FR nXn[n][.n] - USFS Forest Route/Road ref=FT nXn[n][.n] - USFS Forest Trail For county roads in California, I've used: ref=CR Xn[n] + network=US:CA:county_name but this probably needs to be changed to remove the county_name part for the roads that are part of the state-wide numbering Xn[n] system, so as to be able to distinguish them from individual counties' road numbers. That is, I think the statewide-numbered county roads, like S14 in Orange County, should be: ref=CR S14 + network=US:CA:County while San Bernardino County Road 53156 should be: ref=CR 53156 + network=US:CA:San Bernardino -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
At 2012-07-27 06:08, Paul Johnson wrote: On Jul 26, 2012 11:30 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: ref=FH nn - USFS Forest Highway ref=FR nXn[n][.n] - USFS Forest Route/Road ref=FT nXn[n][.n] - USFS Forest Trail IIRC, all three of these are a single NFD network, for National Forest Development, and are distinguishable unambiguously by whether they have two, three or more digits in their number. At least in Region 5 (CA), the roads have N or S in the X position, while trails have E or W. However, I wasn't sure that everyone would necessarily know that, so I went with a more descriptive prefix, based on the terminology Forest Highway/Road/Trail found on the USFS site. Road numbers in other USFS forests seem to be largely numeric, sometimes with a letter suffix. Not sure about trails. Most mentions I see are names, not numbers. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
At 2012-07-27 08:22, Paul Johnson wrote: On Jul 27, 2012 8:07 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: At least in Region 5 (CA), the roads have N or S in the X position, while trails have E or W. However, I wasn't sure that everyone would necessarily know that, so I went with a more descriptive prefix, based on the terminology Forest Highway/Road/Trail found on the USFS site. I figured the situation analogous to the Interstate system, where primary routes are always two digits (5 and 8 being 05 and 08) with three-digit interstates starting in odds being spurs and evens as bypasses as being regionally assumed information. That does not seem to be the case in So Cal. There's a page someone wrote somewhere, outlining some of the methodology. The prefix and letter are loosely related to the township in which a road starts or the range in which a trail starts, but the suffix that follows seems to be just a sequence number. The only forest highway I can think of is SR-39, which is FH-62. Road numbers in other USFS forests seem to be largely numeric, sometimes with a letter suffix. Not sure about trails. Most mentions I see are names, not numbers. One thing that seems to be largely consistent are that highways are two digits, roads are three, and trails are four or more digits, all in the xxyz, where xx is the parent highway (or the primary one it connects to if a road or trail), y is the road and z being the trail number (0 if a direct connection). For example, NFD 4891 is a 4x4 trail connecting to 4x4 trail 4890, which connects to 48. That's useful. I would still suggest using the different FH/FR/FT prefixes, though, for people who don't know that. Ideally, the map should render the roads differently, too, of course, but they don't always seem to be tagged in a way that allows that. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
At 2012-07-27 09:34, Charlotte Wolter wrote: I think you've identified another area where clarity is needed: What order should be used when entering multiple refs. I tend to do it with interstates first, then US routes, then state routes, within each group by number, low to high. However, a definite rule would be helpful. I'm saying I don't think it's necessary. I suppose you could enter the most commonly used by people to refer to it first, in case some consumer decides to just use the first value it sees. 11:29 PM 7/26/2012, you wrote: At 2012-07-26 18:48, Clay Smalley wrote: What if they're equally important and recognized (like Interstate 80/90 through Ohio and Indiana, or US 1/9 in New Jersey)? The consumers should not assume anything from the order. Personally, I enter them in alphanumeric order (I think - its been a while). -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
At 2012-07-27 09:44, Charlotte Wolter wrote: Alan was anticipating a question I was going to ask, whether to use FR (forest road) or FS (Forest Service) or Forest Service spelled out. I have seen all three. Reading his contribution, it seems we should use FR for the tracklike forest roads and FH for a forest highway, which seems OK to me. But, what would be the definition of a forest highway? I haven't seen any major roads (except US or state highways) in national forests, but I work only in the Southwest. It's defined by the USFS. Local examples are FH-62 (San Gabriel Canyon Road - SR-39), FH-61 (Angeles Crest Highway - SR-2). -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
At 2012-07-27 09:58, Charlotte Wolter wrote: On a local note, would that mean that S78 in San Diego County, the one that goes to Anza Borrego, would be tagged ref=CR78 and network=US:CA:Orange? I think you mean (state, not county road) SR-78 here: http://www.openstreetmap.org/?lat=33.097821lon=-116.473045zoom=18layers=M It is correctly tagged ref=CA 78. Note that there _is_ a county route S2 here, which someone has tagged ref=Co S2. What if we called CalTrans and asked the cartographers for an opinion? Maybe someone there knows OSM. What kind of opinion are you looking for? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fwd: Re: Highway ref again.
Here's the page I was thinking of: http://www.cahighways.org/num-forest.html . It links to another good page: http://tchester.org/sgm/lists/anf_map_roads.html . Getting the road/trail names/numbers out of the USFS is difficult, requiring a fair amount of research to find a map on which it is legible, searching for it in their road inventories, etc. I've done some of the unpaved roads in the SB, Angeles, and Cleveland forests with which I'm familiar, but I think there are a lot of trails to do still. BTW, here's the County Route page on that site: http://www.cahighways.org/county.html -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] [Tagging] tagging awards and ratings
At 2012-07-26 14:43, Frederik Ramm wrote: Hi, On 26.07.2012 19:10, Johan Jönsson wrote: Sometimes there is a discussion on how to tag differnt kind of awards and ratings. It is possible that the organisation publishing the ratings has some sort of copyright or database right to them. For example I don't think it will be legal to copy TripAdvisor ratings into OSM. This may be an FAQ, but if a shop posts their awards in public view, don't we have fair use to note it in our data, much like a photographer has a right to photograph, or a news reporter has a right to report, something in public view? What about if the shop advertises on their own or another website, or in a magazine, with that award displayed? Lastly, what about health-department grades, created and (usually) published by public agencies - something I'd like to import and update locally at least? I know that if it's data created by a US Federal agency, it's public domain, but what about US state and local governments (does the same law -- use of public funds = public domain -- apply)? -- Alan Mintz alan_mintz+...@earthlink.net ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-us] Bulk fix of comma delimiters in source tag in parts of CA, NV, AZ, UT
It was brought to my attention that P2 shows a warning that a field contains multiple values when it sees semi-colons in a field. As a result, some had interpreted this as an error, and fixed it by changing them to commas. Since the commas are a legitimate value character, the field no longer looks like it has multiple values and the warning goes away. This behavior is the subject of another thread (on dev, moved to tagging). AFAIK, semi-colons are still the correct way of delimiting multiple values. How consumers and editors deal with this are a separate issue - my concern was to fix these fixes in the area and particular tag I knew where it was occurring - source=*. Using OAPI, I downloaded the relevant objects in the bbox [32,-130,39,-110], sorted them to remove the cases where the comma was a legitimate part of a single value (long English descriptions), and then replaced the commas with semicolons in the resulting 8592 objects. Many of these were not fixes, but were instead entered that way to begin with. Anyone have an issue with me uploading the fixed data? I realize that the issue may exist outside this bbox as well. It might be useful to look for the issue globally. Also, there are probably other tags that legitimately and non-controversially may contain multiple values. I was trying to work out a process, which turns out to be somewhat manual, even with the help of a couple scripts. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Naming disputes in Ukraine
At 2012-07-25 00:33, Frederik Ramm wrote: Hi, I'd like to hear the opinion of others in OpenStreetMap about the following situation that Data Working Group has been asked to mediate. The official language in Ukraine is Ukrainian. ...So, my questions to you are 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? I would say the definition of area should be as local as is reasonable/possible. For many countries, this is certainly sub-national. In a given area, if the vast majority uses a given language, that language should be used/assumed for the name value. It would be good if we had some meta-data somewhere to define this, as well as other defaults/assumptions for an area (e.g. oneway=no except for junction=roundabout and highway=*_link, lanes, sidewalks, maxspeed). If there is no vast majority (say, less than 80%), I would suggest no name tag - only name:xx tags. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Good work with remapping!
At 2012-07-22 23:53, Toby Murray wrote: I also ended up doing some reimporting from TIGER 2011 in the Irvine area because some neighborhoods that were just too far gone to bother salvaging. For example here is a before shot of one area: http://i.imgur.com/pEuIm.jpg (and actually, a couple of those roads are already fixed. I happened to have a P2 instance open after I had uploaded the new stuff from JOSM and P2 picked up some of the new roads before I grabbed the screen shot) Reminder: Orange County, CA has a decent source of official land and survey info (including roads), though it is somewhat slow and only works in IE: http://www.ocgeomatics.com/landrecords/Default.aspx . Here is the current view: http://www.openstreetmap.org/?lat=33.60425lon=-117.81902zoom=15 I decided to follow my previous TIGER remapping strategy[1] and it worked out fairly well. Some of the neighborhoods were gated communities so they only had 2 or 3 roads connecting out to the rest of the network. This made it very easy to remove the existing garbage and import one section at a time. It's a lot more complicated to do a reimport in an area with a regular grid pattern of roads because there are so many more external connections to make. BTW, this neighborhood is unincorporated OC, with USPS addresses in Newport Beach, 92657. Three issues with two of the tracts I checked: 1. In these two tracts (TR15079 @ MM765/11-19 and TR15394 @ MM778/12-19, both in RSB173/34-38), all the streets (except Ocean Heights Drive) should have a prefix of Via, which was apparently missing in TIGER. 2. Christallo, despite being shown as Via Christallo on the basemap, is actually Via Cristallo according to the Tract Map, as well as the addresses shown for the parcels. It's also wrong on the overview sheets of the survey and tract maps, but is correct on the respective detail pages (this type of discrepancy is, unfortunately, more common than you would think). Finally, it is confirmed by looking up the 9-digit ZIP for an address on the street (e.g. 7 Via Cristallo, Newport Beach, CA) on the USPS website (https://tools.usps.com/go/ZipLookupAction!input.action), confirming that it is Via Cristallo. This was one of those that just didn't look right, given the Italian spelling of the other street names in the area, and the h in the incorrect Christallo, which was confirmed by the records. After making the correction and checking alignment with the Bing imagery in the area, I tagged it with: * source=bing_imagery_0.06m_201008;OCGIS;TIGER11;USPS * source_ref=MM765/11;RSB173/34 * Removed the tiger:reviewed=no tag * Added a note tag about the naming discrepancies. Note that I normally use the first date in the imagery range in my source values, indicating the worst case. In this area, however, the range shows a zero date - 01/01/1980-08/30/2010 - so I used the ending date (in mm format - 201008) instead. I similarly aligned and/or checked and tagged the other roads in the tracts. 3. There were a number of orphan nodes tagged with highway=turning_circle left in the area, presumably remnants of the previous ways? In JOSM, these can be found with the following sequence, though there should be a better way that just isn't apparent to me at the moment: a. Find, replace selection, search string=highway=turning_circle type:node b. Find, add to selection, search string=parent selected type:way c. Find, remove from selection, search string=child (type:way selected) d. Find, find in selection, search string=highway=turning_circle type:node This left 6 orphan turning-circles, which I deleted. It's a good idea to turn off background imagery for a moment after wiping an area to catch these leftovers that might otherwise be hard to see. Maybe even do a select-all to make sure they are highlighted for you. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] OT - Unusual Bing imagery
At 2012-07-23 16:02, andrzej zaborowski wrote: On 24 July 2012 00:52, Hendrik Oesterlin hendrikmail2...@yahoo.de wrote: http://greenvilleopenmap.info/Airplane.jpg Nice catch, Mike N. Finding a plane in flagrante used to be quite an achievement in the KHBBS days :) The Bing imagerie could be satellite imagerie, not necessarily air plane imagerie. The area in the screenshot seems to have a higher resolution than satellites can achieve. Is this documented somewhere? Assuming from the look and ratio of measurements of the jet that it is a B737, the pic is at z20 (~12cm/pel @ middle lats). I was under the impression that all of the Bing/Yahoo/Google imagery was still satellite-based, down to z21 (6cm/pel). I know Google has spots of UHR imagery at z22, but it seems they were still referred to as satellite. I've seen individual county websites with very nice imagery described as flyover, as though coming from airplane/helicopter, apparently on a contract basis. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Slippy map with Bing background
Is there a browser-viewable OSM-with-Bing-imagery-mashup somewhere that can be used as citable source for Wikipedia? I'm suggesting OSM as a potential source for accurate coordinates in WP articles, but realize that positioning is not necessarily reliable unless specifically tagged or easily compared against license-compatible imagery. I'm assuming: a) Getting coords from OSM and using them in WP (with cite) is allowed (is there a standard cite format?) b) Looking at the Bing imagery to confirm OSM positioning is allowed, so looking at the two together is allowed to get coords even if the user doesn't choose to edit OSM to reflect them. Note: I checked http://wiki.openstreetmap.org/wiki/OSM_Online_Browsing before writing this - none of the ones with worldwide coverage have the Bing sat imagery. I realize that Potlatch and JOSM can do this - I'm looking for a browser-only, no-login/no-edit solution. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] LA part of the map essentially is unusable
At 2012-07-19 09:06, Robert Kaiser wrote: Charlotte Wolter schrieb: Having looked over the damage and deletions for the last hour, I feel the redaction has left the LA map essentially unusable. Huge blocks of streets are missing, including major roads and some sections of freeways. Sounds like there's a lot of work for the community to do. I'm sure there is a community in LA with the knowledge to put data there that is correct and license-clean. If not, a good chance to build it up! :) There was, yes. Even something that might be called momentum. There are those of us that put in literally blood, sweat, tears, and hard cold cash, who are not happy with the actions of those whose job it was to safeguard our work. That is all I will say. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] LA and other license changeover challenged areas.
[off-list] At 2012-01-30 08:48, Martijn van Exel wrote: On Mon, Jan 30, 2012 at 1:05 PM, Nick Hocking nick.hock...@gmail.com wrote: I have just saved one street in L.A. (Loosmore Street) and hereby award myself one SLAP (Save L.A. Point). [...] Hee, I'd love to earn myself some SLAP points! I did reach out to user blars (who had been contacted before but hasn't decided as yet) and will wait for his response before I start remapping the area I was looking at (around Glendale I believe). I gave it my best job of persuasion, and even managed to get a reply with which I attempted to build a bridge between he and the OSMF, but ultimately, it failed. Even if he accepted now (which is extremely unlikely), it's too late once the redaction happens, right? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] LA and other license changeover challenged areas.
Uh, ignore this. I didn't mean it to go to the list, and, of course, didn't realize it was 5 months old. At 2012-07-19 12:58, Alan Mintz wrote: [off-list] At 2012-01-30 08:48, Martijn van Exel wrote: On Mon, Jan 30, 2012 at 1:05 PM, Nick Hocking nick.hock...@gmail.com wrote: I have just saved one street in L.A. (Loosmore Street) and hereby award myself one SLAP (Save L.A. Point). [...] Hee, I'd love to earn myself some SLAP points! I did reach out to user blars (who had been contacted before but hasn't decided as yet) and will wait for his response before I start remapping the area I was looking at (around Glendale I believe). I gave it my best job of persuasion, and even managed to get a reply with which I attempted to build a bridge between he and the OSMF, but ultimately, it failed. Even if he accepted now (which is extremely unlikely), it's too late once the redaction happens, right? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
At 2012-07-19 13:41, Phil! Gold wrote: * Martijn van Exel m...@rtijn.org [2012-07-19 14:22 -0600]: On Wed, Jul 18, 2012 at 11:42 PM, Toby Murray toby.mur...@gmail.com wrote: Any other common problems that people have seen? Another thing I find is a lot of leftover stray nodes without any tags. I select them in JOSM with type:node tags:0 -child and delete them in one fell swoop. Eeek! Be very careful with this! The unconnected, untagged nodes were left deliberately to facilitate recreation of roads, particularly the case where a decliner split a TIGER way but did not change its geometry. I've been making use of these nodes in South Carolina to reconstruct the roads there. That _is_ a nice feature. One thing I would do (in JOSM) when first loading an area to work on is run the validator. This will find those orphan nodes, as well as crossing ways that don't intersect, etc. - indicators of things that need to be fixed. While it might seem easier sometimes to delete and re-draw objects, be careful with objects that have source/source_ref values, as this says that a user has edited/confirmed that object (with the exception of some of the automated import sources), which should be considered the highest form of authenticity. Be careful of intersections with turn restrictions and their connecting roads. These render with little restriction signs on/near the intersection in JOSM and Potlatch. Unfortunately, TIGER11 still has naming inaccuracies. I recently did this neighborhood with some new construction in Yorba Linda, CA: http://www.openstreetmap.org/?lat=33.8987lon=-117.8017zoom=14layers=M and put note tags on a number of roads that required research that ultimately contradicted TIGER. I think there were a couple more that were wrong that I did not annotate. That would be roughly 1-5% of the roads in the area, and a larger %age of the new roads. I've had a similar experience with new construction at Fort Irwin, CA and Victorville/Hesperia, CA. It seems to be worse for new construction areas, presumably because TIGER eventually gets some feedback to correct it. The issues are often obvious - look for mis-spellings of common words, lack of prefix or suffix (i.e. missing Via, Camino, St, Ave, Blvd), etc. Also look for names that are different from the pattern used in a given area, e.g., Piazza Maria, Piazza Angela, Piazza Gina, George, Piazza Donnatella. George is probably wrong here (missing prefix, non-Italian man's name). I will say that TIGER11 road positioning and connectivity generally seems good now, even enough for GPS guidance. Bing imagery is available down to zoom 19 (~26cm/pel) in virtually any area with a road, and even zoom 21 (~6cm/pel) in the most populous areas (though some of the patches close to downtown LA are jagged, and look better at z19). I've confirmed that alignment accuracy is within about 5m of known benchmarks (personal surveys, FAA VORs, USGS benchmarks, CORS stations, etc.) at many points - enough to satisfy me that the imagery can be used. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] [Rebuild] Progress update
Richard wrote: ...Given people's constraints on time and the community's (understandable) desire for the redaction to get underway asap... I've seen no such demonstration of desire. The only thing we real mappers are discussing is anxiety over exactly what will happen and when, and the huge amount of data that is tainted and will be lost when this thing is shoved down our throats. At 2012-06-21 08:02, Evin Fairchild wrote: There is still a lot of remapping to be done, especially in Los Angeles area where there are several mappers whom have not accepted the new license... ... Are you guys really willing to let this much data go down the drain? There is also a similar issue in other cities and countries, including London, Germany, and especially Poland. What is going to be done about all this data? And why didn't the OSMF step in and help, since they were the ones forcing this upon us? And Richard responded: Evin - this is a list for technical discussion of the rebuild project. If you have policy or mapping questions, there are more suitable channels, in particular legal-talk@openstreetmap.org and osmf-t...@openstreetmap.org. Thanks. Is this really the problem? Have we been barking up the wrong tree? The osmf-talk list isn't even in the list of lists - you have to know it's there and then go to http://lists.openstreetmap.org/listinfo/osmf-talk, and it apparently requires approval by a human administrator to get onto it. Is that the community you've been listening to? Your board members and lawyers? (I'm sorry for the tone and the cross-posting, but we've been unable to get the board to engage in a substantive discussion about a solution to the bad data problem. Instead, there's just this seemingly-mindless progression going on. I'm want to make sure the real mapping community knows what's going to happen to their data and hope they'll speak up about it.) -- Alan Mintz alan_mintz+...@earthlink.net ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] [Rebuild] Progress update
Richard wrote: ...Given people's constraints on time and the community's (understandable) desire for the redaction to get underway asap... I've seen no such demonstration of desire. The only thing we real mappers are discussing is anxiety over exactly what will happen and when, and the huge amount of data that is tainted and will be lost when this thing is shoved down our throats. At 2012-06-21 08:02, Evin Fairchild wrote: There is still a lot of remapping to be done, especially in Los Angeles area where there are several mappers whom have not accepted the new license... ... Are you guys really willing to let this much data go down the drain? There is also a similar issue in other cities and countries, including London, Germany, and especially Poland. What is going to be done about all this data? And why didn't the OSMF step in and help, since they were the ones forcing this upon us? And Richard responded: Evin - this is a list for technical discussion of the rebuild project. If you have policy or mapping questions, there are more suitable channels, in particular legal-t...@openstreetmap.org and osmf-t...@openstreetmap.org. Thanks. Is this really the problem? Have we been barking up the wrong tree? The osmf-talk list isn't even in the list of lists - you have to know it's there and then go to http://lists.openstreetmap.org/listinfo/osmf-talk, and it apparently requires approval by a human administrator to get onto it. Is that the community you've been listening to? Your board members and lawyers? (I'm sorry for the tone and the cross-posting, but we've been unable to get the board to engage in a substantive discussion about a solution to the bad data problem. Instead, there's just this seemingly-mindless progression going on. I'm want to make sure the real mapping community knows what's going to happen to their data and hope they'll speak up about it.) -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Work on Arizona rail lines deleted
At 2012-06-19 10:27, Charlotte Wolter wrote: I did a lot of work on the railroad that parallels I-40 across Arizona, from Gallup, N.M., to Flagstaff, Ariz. There are two parallel tracks with different names, but OSM had only one of those tracks. I added the second rail way and numerous side tracks, following the Bing imagery. It was hours and hours of work. Now someone has deleted most of the second line without contacting me or discussing the issue on the mail list. Anyone know anything about this? Can you be more specific? The places I looked had your rail and another unnamed one. BTW, if I don't have the names, or don't care to name them separately, I add tracks=n (where n is the number of tracks) to a single way to indicate multiple parallel tracks, and position the way in the middle. Same applies to yards if I don't feel like drawing umpteen parallel ways. I run a single way roughly through the middle and add tracks=a;b;c, where a in the number of tracks going into the yard, b is the maximum number of tracks wide in the yard, and c is the number of tracks going back out (in the direction of the way). I then use a landuse=railway closed way to surround the yard. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Unauthorized mechanical edit - changeset 11913785 - amenity=airport-aeroway=aerodrome
At 2012-06-17 03:38, bruno wrote: Hi! without too much thinking and without discussing it (and without reading the wiki) I made a worldwide mechanical edit http://www.openstreetmap.org/browse/changeset/11913785 https://wiki.openstreetmap.org/wiki/Mechanical_Edits/White_Rabbit I modified 1120 elements which had the amenity=airport tag: * those which already had aeroway=* were just stripped of amenity=airport and the aeroway=* was left untouched; * those elements with just amenity=airport and no aeroway=* were stripped of of amenity=airport and added aeroway=aerodrome. I have the old version of the nodes [1]. I'm sorry for the mess :-| What do we do? I'm not sure what the issue is here. Why do people think this needs a complete revert? Is amenity=airport documented or supported anywhere? Isn't it likely that these _are_ mostly airports (which, of course, should have been verified first)? While the Korean schools are certainly wrong, I'd bet that most of them were, mis-tagged airports. I'd ask the original contributor why the schools were tagged that way, if possible. Otherwise, take the opportunity to look at the names, other tags, imagery, etc. in determining which of the edits should remain. According to taginfo, there are a _ridiculous_ 7641 values for the amenity tag, the vast majority of which have single-digit quantities (i.e. less than 10 occurrences). It seems people are just blindly making shit up instead of trying to figure out the correct tag to use, and this problem is only getting bigger. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Custom Imagery
At 2012-06-17 20:51, Alex Rollin wrote: I am looking into how to use custom imagery for tracing. Can anyone point me at a process, and how-to? I was looking at the Digital Globe site, thinking of buying some images. I've used the PicLayer plugin for JOSM successfully. It has tools to stretch/compress and align the image correctly and then save the resulting calibration for future use. It's suitable for a reasonably small area - ideally one screenful at the res that you want to map, but you could zoom up a level or two without hurting your results too much (i.e. 16 screens' worth of image). Basically, you need calibration targets on the image with known lat/lon values. Normally, you have this for at least the four corners. If there is another in the middle, that's even better for verification. You then use the PicLayer tools to align those points with the same lat/lon in the JOSM viewport. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] new bing hires updates not visible in JOSM?
At 2012-06-12 17:39, maning sambale wrote: As the subject says, we spotted new imagery from Bing. Potlatch2 can load the imagery, but JOSM still shows the lowres Landsat image of the same area. This area for reference: http://www.openstreetmap.org/?lat=9.305565lon=123.308057zoom=18 Using JOSM r5181: In that area, I can get down/in to zoom 19, dated 2011-09-14. This is 0.3m/pel (~30m on the 1 scale bar) - enough to see individual cars and the buildings with which some OSM ways are poorly aligned :) Unfortunately, there is some cloud/fog-cover that obscures some areas completely. The high-res extends west only to ~123.265 deg longitude and, when zoomed down/in further than about zoom 14 (9.4m/pel (1:940m)), there is no imagery at all west to ~123.245 deg (a swath ~2200m wide), before the zoom 13 (18.8m/pel, 1:1880m) imagery area. That should probably be reported. Bing tends to have these at interfaces between different image sets, but there are usually just a few meters, unlike this one. The imagery cache path is given in the Preferences dialog, Advanced Preferences, key imagery.tms.tilecache_path. Under that directory, there are separate directories for each particular WMS/TMS source, each of which contain a ton of files. I don't know what it's like on a Mac, but it takes many hours to remove those directories on Windows (the subject of a recent JOSM change request) if you want to flush the cache. You can also flush the cache for a particular source by creating a layer with it in JOSM, then right-clicking (or whatever your context-menu-key is) and choosing Flush cache. This may be quicker, or not. Lastly, or maybe firstly, check the Imagery URL you are using (Preferences-Imagery Preferences). It should be bing:http://www.bing.com/maps/;. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
At 2012-06-15 02:04, Kate Chapman wrote: I'm looking for examples of governments using OSM data Not huge, but nice: http://www.whitehouse.gov/change/ -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Copy-and-paste remapping
At 2012-05-28 14:17, Frederik Ramm wrote: Where cases of copy-and-paste remapping are detected, the changesets in question can be added to the list on this wiki page http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Copy_-_Paste_Remapping and will then be treated during the relicensing process as tainted, i.e. the data created in these changesets will not be kept. There are two drawbacks to this: 1. OSM Inspectors's license change view does not take this list into account, i.e. the areas thus remapped still look clean on OSMI even though they will be dropped later. Wow - that's bad. Is there a reason this can't be implemented quickly? Doesn't it already have the concept in the positive direction with the listed clean changesets? Is the functionality the same on the JOSM license plugin? Looking at the description of the first set and random samples of the next two, it seems they are all in Europe. Is that correct? The last three are not linked. Is there a reason for that, or should I fix it? It might be useful to give at least overall bbox info - I'll work on that. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM : It's a shame !!!
At 2012-05-28 12:42, ce-test, qualified testing bv - Gert Gremmen wrote: After having been banned from OSM for not signing the CT, my contributions, that have been well received by the community in the past have been removed by the april 1st license shift. No. I don't understand why the responses so far haven't mentioned the most glaring reason for this. The license-compliance redaction has not yet begun! Even your data that haven't been touched still remain because they have not yet begun the process of removing the non-compliant data (thankfully). -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Copy-and-paste remapping
At 2012-05-28 17:05, Frederik Ramm wrote: The last three are not linked. Is there a reason for that, or should I fix it? It might be useful to give at least overall bbox info - I'll work on that. Adding links quadruples the amount of data on the page so I'm not a huge fan of links (don't trust Mediawiki) but if you think it is useful... where usernames are given, Pascal's OSM heatmap is a good indication of where that user was active. I worked up just the first example at http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Wikipedia.2Cetc._imports_in_Czech_Republic The rest are easily done now that I have scripts for it, but I get that the page might get overwhelmingly large. How about sub-pages for each section with my tables, and just the plain-text lists, a link to the sub-page, and the summary line on the main page? -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import of buildings in Chicago
At 2012-05-28 05:02, Mike N wrote: On 5/27/2012 2:53 PM, Alan wrote: As I discussed with you, I am no longer uploading data with the tag and will go back to remove the tag from the existing data. I object. An ID tag is highly useful for future reconciliation and/or synchronization later. I used to agree with you, but in terms of minimum labor, updates are best performed by retaining the original upload data, then doing a conflation between the original data and a later update. That will highlight only changes from the original source, and only those differences will need to be manually merged into OSM. Except you won't see possible errors introduced after the first import by OSM editors. I think it's useful to see the diff between the current state of both databases. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM data density - top regions
At 2012-05-27 14:30, Frederik Ramm wrote: As of 27th May 2012, only 142 of these meta tiles have more than 100,000 nodes on them; the front-runner has a whopping 227,000. 105 are in France, 26 in the US, 3 each in Italy and Brazil, and one each in Spain, Japan, Denmark, Austria, and Indonesia. Of the US tiles, 6 are Kern County, CA and 9 are Cook County, IL, both of which have been the subject of recent discussion here about import of building outlines. Here are some details about a small piece* of one of these Kern County tiles: 1667KB OSM XML 6036 nodes: - 5702 nodes that are part of building ways - 256 trees - 69 highway nodes 525 ways - 489 building ways - 34 highways That is to say this medium-density (4-5 houses per acre) residential neighborhood would have 78 nodes (1.3% of current) and 36 ways (6.9% of current) without the building outlines and trees. The OSM XML would be 31KB (1.9% of current). * 0.5 mi x 0.5 mi (800 m x 800 m) at minlat='35.3979622' minlon='-119.1277814' maxlat='35.4052032' maxlon='-119.1188657' -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Worst of OSM
I didn't understand the comment about Minecraft. Did they think there was a problem with the square forest boundaries? Did they not realize that those are likely the actual defined boundaries of the forest (at least that's what they correctly look like in southern California)? Also, I don't think there's anything wrong with address points with no building outlines. San Diego, CA is full of that (from an import). It would be impossible to map with Potlatch (it's already tough) if someone added building outlines to this already-quite-dense area. It only recently became reasonable to map with JOSM because of the ability to filter the download process. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Worst of OSM
At 2012-05-15 07:10, Pieren wrote: On Tue, May 15, 2012 at 3:56 PM, Maarten Deen md...@xs4all.nl wrote: The problem with the spanish place names is not that there are no roads connecting them, the problem is that they are not places. The area is unpopulated. But they are all tagged with place=locality which is correct for unpopulated places (http://wiki.openstreetmap.org/wiki/Locality). Maybe. Is it possible that those are not real villages, but names of historical villages or settlements (and shouldn't be tagged as current placenames)? Can someone in Spain comment? -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Worst of OSM
At 2012-05-15 09:25, andrzej zaborowski wrote: Maybe the fact that it's German (assuming that it is) is a sign of OSM's popularity there, and approaching Google Maps. The caption language doesn't really sound like DEnglish, or even UK English, though. The spelling is American English (e.g. visualization). -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Blocking of user WorstFixer for removing ele=0 etc
At 2012-05-13 02:49, Frederik Ramm wrote: Removing ele=0 from objects is, in my opinion, totally unnecessary; And maybe incorrect, as ele=0 means we know the elevation is 0, while no ele tag means we do not know the elevation. like created_by, over which WorstFixer made a similar fuss, such information could be removed where an object is touched for some other reason but I don't see why it would have to be mass-removed. The reason for this may not be obvious to some. I assume it's because we store history of all objects, and it's a waste of space, not to mention bandwidth and processing resources to push the changes out to the mirrors, for almost no benefit. I just add created_by='' to my JOSM presets (or maybe it does this automatically now) so I clean it up when performing other edits. Even so, a mass-removal would be ok if proposed, discussed, and accepted by the community like we expect everyone to; it's not ok to just do it on your own and see if someone notices. Yes. Having said all that, OSMTI says there are 23 million nodes (33% of the total) with created_by tags! This seemed surprisingly high to me. I retrieved nodes from 300 random 0.1x0.1 degree bboxes. Of those, only 37 returned any nodes at all**. All but 6 of those areas had no created_by tags on their nodes. Of those, only 2 were significant in percentage*, both in Norway. #137 had 1558 nodes, 801 of which (51%) have created_by tags. BLTR: 68.13713.766 68.237 13.866 #264 had 2297 nodes, 1946 of which (85%) have created_by tags. BLTR: 60.787 4.900 60.887 5.000 In #137, they are mostly tagged: tag k=created_by v=JOSM/ (TI says this makes up 63% of the values) In #264, they are mostly tagged: tag k=created_by v=almien_coastlines/ (TI says this makes up 10% of the values) tag k=source v=PGS(could be inacurately)/ My questions are: 1. Would removing the created_by from 33% of the nodes in the database save significant storage space, dump size, backup time, etc.? 2. Is it possible to remove these in bulk from the database without having to keep the history, push those diffs to mirrors, etc.? Do the mirrors occasionally start fresh from a new dump? Or can they run the same bulk purge? Or do I overestimate the necessity of doing it this way (and we can just clean it up with the regular tools and processes)? * While not a significant portion of the total nodes in the area (only 4%), there were almost 600 created-by-tagged nodes in this file from England: #123 had 14013 nodes, 594 of which (4%) have created_by tags. BLTR: 51.0860.088 51.186 0.188 ** I guess this clarifies why old satellites that fall from their orbits and other space junk never seem to hit anything, even if they survive re-entry :) -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blocking of user WorstFixer for removing ele=0 etc
At 2012-05-15 15:21, Toby Murray wrote: On Tue, May 15, 2012 at 4:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: Yes. Having said all that, OSMTI says there are 23 million nodes (33% of the total) with created_by tags! This seemed surprisingly high to me. Err last time I checked we had over 1 billion nodes. So 2% not 33. I'm guessing that Taginfo drops (understandably) any objects without tags before it analyzes the data, and the percentages are based on this filtered number of objects. There are 1,458,341,105 nodes, only 70,486,257 of which have any tags. 33% of _those_ (70M) have created_by tags. TI maintainers: Would you think about basing the percentages on the total unfiltered counts and possibly adding rows for no tag to the lists where appropriate? My questions are: 1. Would removing the created_by from 33% of the nodes in the database save significant storage space, dump size, backup time, etc.? 2. Is it possible to remove these in bulk from the database without having to keep the history, push those diffs to mirrors, etc.? Do the mirrors occasionally start fresh from a new dump? Or can they run the same bulk purge? Or do I overestimate the necessity of doing it this way (and we can just clean it up with the regular tools and processes)? Not even the license change bot is going to completely delete/hide history and I think it is going to be the biggest automated change in the history of the project. It will cause some parts of the history to be hidden from public view but they will continue to exist in the database. Makes me wonder... how many created_by tags are going to be nuked by the license change bot? :) I can understand why that is - it's being worked on by many people, may need partial revertability, will probably run for a long time, etc. Removal of one tag in bulk doesn't present these issues, and may be possible, which is why I'm asking: a) does it help; and b) is it possible? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] near by
I didn't see the original post, so pardon me if I'm off-target. I wanted to mention that, when working with small distances and areas, I generally use the geo formulas once to calculate the distance/degree ratios for latitude and longitude at one point*, and then just convert other nearby lat/lons to relative distances with pythagoras. It's far less computationally intensive, and good enough for many purposes, including finding the closest object, smoothing ways, getting approximate bearings, etc. For example, at 34 deg lat, latitude is 110922.416 m/deg and longitude is 92384.593 m/deg. At 33.5 deg lat (55 km south), lat is 110913.401 m/deg (0.008% less) and lon is 92922.354 m/deg (0.6% more). Using a traditional, computationally expensive formula, the distance between first point A(34.1, 120.0) and second point B1(33.9, 120.2) is 28871.232 m. Using the constants for 34 deg lat above and pythagoras, you get dY=22184.483 m and dX=18476.919 m. Diagonal distance d = (dY^2 + dX^2)^0.5 = 28871.228 m (almost exactly the same). For a second point B2(34.35, 120.15), the distance A-B2 using the expensive formula is 30984.896 m. Using the 34 degree factors, it is 31000.353 m (error of 0.05%). For a second point B3(34.6, 121.3), the distance A-B3 using the expensive formula is 131838.294 m. Using the 34 degree factors, it is 132287.371 m (0.34% error, even for such a large distance from the reference point) If you don't care about the actual distance values, just their relative sizes, you can drop one more multiplication from the calculation by determining the ratio of the lat m/deg to the lon m/deg factors, then scaling the latitude diff by that factor and feeding the result, along with the longitude diff, to pythagoras: For the factors for 34 degrees above: latitudinal degrees are 1.200659x as long in meters as longitudinal degrees. So, multiply dY (change in lat) by this ratio and then apply pythagoras to get a mythical unit (call it foo) value. For A-B1, dY=0.2*1.200659, dX=0.2, d=0.312511 foo. For A-B2, dY=0.25*1.200659, dX=0.15, d=0.335558 foo. This is 1.0737x A-B1. Note that this is the same ratio as the distance values calculated above (31000.353/28871.228). For A-B3, dY=0.5*1.200659, dX=1.3, d=1.43192 foo. This is 4.5820x A-B1. Note that this is the same ratio as the distance values calculated above (132287.371/28871.228). And these are all relatively long distances. When you're looking for the nearest bus stop, intersection, etc., these approximations work quite well. At higher latitudes, accuracy starts to decrease, but is still within 1% out to 10s of km at 60 degrees lat. * I don't recall the basis for these. They seem to come quite close to traditional calcs like http://www.ngs.noaa.gov/cgi-bin/Inv_Fwd/inverse2.prl. It's possible (even likely) that some of the constants in the main formulae are geoid-dependent - I've only worked with this using the GRS80 spheroid (for WGS84). $nMidLat is the latitude of interest. $cnPi = 3.1415926535897932; $cnSphA = 6378137.0;# Equatorial radius in meters (GRS80/WGS84) $cnSphB = 6356752.3141;# Polar radius in meters (GRS80/WGS84) $cnSphF = ($cnSphA - $cnSphB) / $cnSphA;# Flattening factor $cnSphCDeg = ($cnSphA * $cnPi) / 180.0;# Meters per 1 degree longitudinal arc at 0 latitude $nMidLatRad = $nMidLat * $cnPi / 180.0; # Horizontal meters per degree: $gnHMult = (1.0 + ((sin($nMidLatRad) ** 2.00362) * $cnSphF)) * $cnSphCDeg * cos($nMidLatRad); # Vertical meters per degree: $gnVMult = $cnSphCDeg * 0.993307 * (1 + (3.018996 * (sin($nMidLatRad) ** 2.00985) * $cnSphF)); At 2012-05-09 06:48, Ramiro Cosentino wrote: Re all, I've found a solution which works for me. It's basically an implementation of the Haversine function for ruby taken from here http://www.esawdust.com/blog/gps/files/HaversineFormulaInRuby.html There is another one I haven't tried here: https://github.com/almartin/Ruby-Haversine The only drawback is that I got to fetch all the db records which are around 500 and apply haversine distance to each compared against users's current location (which is provided by the phone). Thanks everyone for the input! It really helped me find the right direction, or at least reasonable. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-10 19:40, Anthony wrote: On Thu, May 10, 2012 at 10:25 PM, Mike N nice...@att.net wrote: The only question is what to do about those cases where it's only referred to locally as 'Ave', and the postal service would refuse letters addressed to 'Avenue'. The postal service would refuse letters addressed to Avenue in some instances? Unless this quote is out of context, that seems ridiculous (in the US). -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-10 19:56, Anthony 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. Exactly :) Why that is ok, I don't know :( -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-11 10:20, David ``Smith'' wrote: Third, I suggest retaining the abbreviated form in a tag like abbr_name. Ideally, this should be the exact abbreviated form used on signs, if that's consistent. Getting this right requires local knowledge, but TIGER's abbreviation might be better than nothing. I'm sure some will disagree with that point. Better yet, since a proper expansion bot has to chop up the name into its components, why not take the opportunity to advance the project by tagging (and re-abbreviating if necessary) those individual components (e.g. street:dir_prefix, street:name, street:type, street:dir_suffix)? That, I could support. One field with the full name for the text-to-speech consumers, and another set of fields to properly identify the street the way others do. Fifth, renderers must take care in abbreviating street names. For example, Mapquest Open turns Lane Avenue into Ln Ave, where only the last word should be abbreviated. To eliminate guesswork, renderers can use the abbr_name tag, if present. Wouldn't happen with street:name=Lane, street:type=Ave (since it would not speak street:name verbatim) -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
At 2012-05-10 09:33, Nathan Edgars II wrote: Is this a good idea? It looks really odd to me: http://www.openstreetmap.org/browse/way/9061339 I don't like it. There are some more in that changeset, and another previous one for that user too. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
There are 52 of these United States Ship ways. OAPI query: http://www.overpass-api.de/api/interpreter?data=(way[%22name%22~%22%5EUnited%20States%20Ship%20%22];node(w));out%20meta; -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-11 14:11, Mike N wrote: On 5/11/2012 1:36 PM, Alan Mintz wrote: Okay, so basically we're ignoring the on-the-ground rule in order to map for the renderer. Exactly :) Why that is ok, I don't know :( Mapping for the renderer has never been wrong or discouraged. Tagging incorrectly for the renderer is another story... That is not my recollection. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
At 2012-05-04 11:47, Paul Johnson wrote: On Fri, May 4, 2012 at 11:37 AM, Paul Norman penor...@mac.com wrote: From: Paul Johnson [mailto:ba...@ursamundi.org] Subject: Re: [Talk-us] Fresno castradal imports On Fri, May 4, 2012 at 1:37 AM, Paul Norman penor...@mac.com wrote: More information isn't necessarily bad; I think it might be better to try to refine the imported data over time if possible. To clean up http://maps.paulnorman.ca/imports/review/fresno.png I would start by deleting most of the data. I fail to see the problem with what's already there. A couple of users, one local, have commented that the issues with the import make it difficult to edit in the area. I really can't see a way short of deleting it. JOSM's filter plugin helps a lot, you know. ;o) Not really. It doesn't solve the 50K object limit of the main API. The mirrored-download plugin does solve that issue in that it will answer the request, but you still end up with an OSM XML file several times the size of a similar area without such data, and JOSM is slow to unusable in loading and many other functions, regardless of the filter, which only helps with rendering time, and not saves, finds, etc. Try to work with a 100MB file is JOSM (instead of a 10-20MB for the same area elsewhere) and you'll see what I mean. Overpass API now has the potential for solving this particular problem (editing with JOSM) if we can get it implemented in JOSM downloader or mirrored download plugin, as long as someone doesn't start joining those landuses to other objects (e.g. highways), again. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
At 2012-05-04 01:37, Paul Norman wrote: See http://lists.openstreetmap.org/pipermail/talk-us/2012-April/008032.html for the full discussion around the removal In summary: - The Fresno import has a number of issues - No one is opposed to removal if there are no easier options for cleaning up the data - No one has proposed an easier option ? Both SteveA and Nathan Mixter (the original contributor) have responded in this thread, co-operatively. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Are US freeway relation licensing issues being worked on?
Is someone attending to license cleanup for US freeway relations nationally, or is it up to mappers in each area to deal with? I'm still seeing warnings in southern California, but have been ignoring them thinking someone is already working on them. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno castradal imports
At 2012-05-04 15:52, Martijn van Exel wrote: ... I do agree that there's an opportunity for crowdsourcing in cadastral surveying, but we should be approaching that very carefully and in the right order. First examine the legal implications of letting the world at large have r/w access to cadastral parcel geometry. Then bring government and OSM folks together to sort out if and how OSM could be a platform. And then import and conflate data. As far as I know, nothing tangible has been done to complete steps 1 and 2, and here we are discussing step three. I don't think it's quite time for that yet. I'm interested in having that discussion, but we do need some common ground about what and for whom OSM is. ...and we need to examine what our existing user tools and server processing and storage resources are and how they can handle the amount of data desired before just blindly throwing many times the existing data size at them. In Bakersfield, the building outlines and some landuse and other objects inflated the data size by ~1000%. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What happened to the license-change highlighting in Potlatch 2?
At 2012-05-01 13:24, Clifford Snow wrote: josm ... It would be nice to be able to hit a key to add a turning circle to the end of a way. Indeed. http://josm.openstreetmap.de/ticket/3484 -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [OSM-dev] Overpass API questions
At 2012-04-27 09:37, Roland Olbricht wrote: Alan Mintz wrote: Another problem appears to be that [key!=value] filters out any way that does not have a key tag at all, in addition to those that have key=value, which is not what I need. Yes, this has been the behaviour expected by design. The rationale behind this is to filter for oneway but not oneway=no. *The point of this is to be able to eliminate ways and their nodes that account for up to 90% of the data being downloaded (i.e. inflating the data by 1000%) when they are unnecessary for a particular editing session. However, this is a convincing argument. For this reason, and because the negation has not found widespread usage so far, I will change the semantics of != in the very next version 0.6.98. Version 0.6.98 is scheduled to be released on Monday, 30 April. This means, from 30 April on, you can get with the above query what you intended to get. Wow - that's great. I was going to suggest maybe an alternate syntax, so either could be done. Like maybe: [not(key=value)] would include only ways without key=value and [key!=value] would continue to include only ways with key tags, and their values not equal to value -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Rebuild] update 25 April
At 2012-04-25 13:20, Richard Weait wrote: Hello, Rebuilding continues. Redaction tests are still being refined. According to best estimates we are close to cracking this, but it's a complex area - passing tests will be the benchmark here. Of the remaining tests, five concern nodes, seven concern ways, five concern relations and 1 relates to significant tag changes. There were more than 20 commits[1] to the license change branch of the code this week, from four authors. Your contributions are welcome. Once the tests are passing, live data testing will be conducted against a test server that is already configured and waiting. Subject to a successful test, a bounding-box test of the live database will be processed, most likely for the island of Ireland. After this successfully processes, the rest of the data set can be processed to completion. I'm sorry to be dramatic, but this is scarily imprecise! What happened to the idea of giving notice before working on the live database? What about the areas of the world previously identified where there is a large percentage of data that would be redacted? This is UNACCEPTABLE to mappers in those areas, as it should be to the rest of the project. Also, while some originally objected to the huge amount of license-related discussion going on on the talk list, it seems like important things like progress updates need a wider audience than just the rebuild list. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Fresno castradal imports
At 2012-04-26 07:59, Nathan Edgars II wrote: On 4/26/2012 2:54 AM, Paul Norman wrote: I happened across an import of Fresno castradal data from mid-2010 in the Fresno area. http://www.openstreetmap.org/?lat=36.77lon=-119.81zoom=15 is the general area but I haven't fully explored the extents. For a view of the data, see http://maps.paulnorman.ca/imports/review/fresno.png The biggest problem with this import is that it's impossible to download any reasonably-sized area of Fresno for editing, because of how the landuse polygons end at every street and alley. It's even worse in the suburbs where the streets curve, adding many nodes to each way. (By the way, the word is cadastral, not castadral. And I see nothing wrong with using such data as part of a semi-manual process of creating larger landuse polygons for neighborhoods, and commercial strips surrounding highways. See Orlando, FL for a (mostly fully-manual) example of how this works.) +1 No wonder they thought I was you on IRC last night. That explains some things. Bakersfield suffers from a similar problem, in that every building is mapped. Landuse polygons, though at least not for every lot, are still over-digitized, and individual trees were imported. To those that say download smaller pieces - you're doing something wrong, I say: I've got 68000 km sq of area to get through - that's 680 x 100 km sq, and even some of those, what I believe should be, reasonably-sized pieces are 160MB, making them completely unusable in JOSM, even with the filter. You are wrong. It's not unreasonable to want to download once, do a large edit, and upload again. There are plenty of things that require this, like license review, tag correction, large surveys, etc. Why should I be forced into so many tiny downloads. Even semi-automated with JOSM remote-control, it's still a PITA with every 10-20th download hanging, having to figure out what size pieces to use, etc. Part of the problem is solved by the mirrored download plugin in JOSM, which does not suffer from the 5 (or whatever) item limit, and is generally much faster at delivering data. At least you can send one download request and go have a beer, because you'll need it when you get back to wait seconds after every screen drag, mouse click, find, etc. even when java is given 1GB RAM on a 2.8 GHz dual-core. I imagine Potlatch is similarly afflicted in such dense areas, as it has to deal with about 10x as many objects as areas without this sort of detail. Some would prefer to solve the problem by removing such data and preventing this kind of micro-mapping. I say we need to find a solution to accommodate it if it's so important to be all things to everyone - but we can't just blindly say deal with it, as was the initial response last night. One limited solution is to be able to filter the downloads, which seems possible using the Overpass API - the subject of another message. Implementation of a not filter in XAPI was also discussed. In the particular case of licensing review where you are only adding/editing tags, and not deleting or moving nodes, it is reasonable to be able to exclude these buildings, landuses, and (mostly fictitious) streams from the download, which would speed both the download and subsequent editing tremendously. In areas where (thankfully) landuses do not share nodes with anything else, a much broader set of mapping workflows does not require them to be present. Certainly, one could exclude individual trees and address nodes from most editing sessions that aren't dealing with those items specifically, which would help greatly in the Bakersfield and San Diego areas, respectively. An even better filtering implementation would add back in any filtered objects that shared nodes with any objects present in the download, in much the same way that the API map calls include the full extent of ways, even outside the bbox, if they have any nodes inside the bbox, and any relations that refer to anything in the result set. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
At 2012-04-16 20:41, Toby Murray wrote: On Mon, Apr 16, 2012 at 8:37 PM, Nathan Edgars II nerou...@gmail.com wrote: On 4/16/2012 9:18 PM, Alan Mintz wrote: At 2012-04-16 14:06, Nathan Edgars II wrote: Or you can simply add odbl=clean if there's nothing ungood about the object (e.g. it was split from a TIGER way and the splitting is something you would have done anyway). Is this really sufficient? Can someone from the redaction squad comment? Can I protect/bless a way or node and prevent its redaction simply by (in good faith) adding this tag? We have no idea what rules the OSMF will use. Well I won't claim that communication has been great but this statement is a little over dramatic. First of all: odbl=clean *will* be honored. ... On nodes as well as ways? As I wrote earlier, if I have tagged a way with a source that includes imagery, and removed the tiger:reviewed=no tag, it means I have aligned it to that imagery, including leaving nodes that are in the correct place alone (sometimes). Can I bless the nodes in the same way? Also there is this: http://wiki.openstreetmap.org/wiki/Open_Data_License/What_is_clean%3F A nice empty page. Tough to argue with :) And of course the code is available for anyone to view... although I'm not going to claim that this is really good documentation on the matter: https://github.com/zerebubuth/openstreetmap-license-change Nor can you reasonably expect people to use this as a guideline. And I'm a programmer. There has been talk of the v0 rule which I believe is being implemented in the code. This means that the act of creating an object by a decliner doesn't automatically make it dirty. So if a way was created by a decliner with the tag name=Fred and then someone else added the tag highway=footway then after the bot gets done with it, the way will still exist but only have the highway=footway tag. If an accepting user changes the value of the name=* tag then it will be clean... except, see the next paragraph. However if all of the way's nodes are dirty and get removed then the way itself will have to go too since you can't have a zero-node way. I contend, though, that you should not have to change a node to make it clean. If one has tagged a source with an imagery (or GPS) value, they are saying that they vouch for the position of the way, including its nodes. Same applies to removing tiger:reviewed=no (or gnis:reviewed=no). The user is specifically claiming to have reviewed the position and tagging and approved it. Should that not be sufficient? Unfortunately neither badmap nor OSMI fully implement all of these rules so yes there is still far too much uncertainty. But there are some facts to be had. Why, then, is it acceptable for us to be sitting here with a dagger hanging over our heads, uncertain as to when and how it will fall? Shouldn't all of this be nailed down, followed by a reasonable notice period? Why is there a deadline other than we need to get it done for the long-term benefit of OSM? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
At 2012-04-16 13:24, stevea wrote: At 2012-04-12 17:36, you wrote: I see excellent progress in California during the recent eight days of re-mapping. If you are an editing maniac... Can you comment on your process? I see very little real, coordinated info about tools, concrete solutions, or teamwork. As a formerly quite active SoCal mapper, I'm basically just dead in the water, wondering how much of my hard work has just been discarded (e.g. speed-limits, lanes, turn restrictions, source references, carefully aligned geometries, etc.) and whether to bother trying to get it back. I can't possibly be alone (?). Sure, Alan. I'll try to help by explaining a core of my process, and you and others can take it from there. Great job - thanks for this. I'm sure it helps. 7) For ways (I'm not going to explain points), here is what I do: Select a bad way by double-clicking the way in the data loss list, Press 3 (JOSM's shortcut for the View menu's Zoom to selection verb (critical, as it centers JOSM), Copy (could be command-C or another keyboard equivalent, again I'm on a Mac), Either Paste-Delete or Delete-Paste ... Now, the new (pasted) bad way is there, and the old bad way is deleted, but the new one is just floating. There are two critical sub-steps here: first, use Bing Sat layer to visually verify. This makes the new way legal in the sense of I, the new editor of this way, have verified it. (I do this for motorways and streets I can see in Bing Sat layer, but not for POIs unless I personally know them). So, we're basically duplicating the existing way and then blessing it. Is this really sufficient - to verify the tainted geometry instead of re-drawing it? If so, why is it not sufficient that, in many, many cases, the original creator of the way has not accepted CT, but many other accepting mappers have afterwards aligned (i.e. moved nodes) and tagged (in my case, with sources of sat imagery, local photo survey, county records, and/or even GPS survey) it? Haven't I already blessed it? Can't the redaction bot look at the source tag and see this? Another point, at least in SoCal, is that many of our tainted ways are created by blars, who has not accepted the CT. However, these are TIGER-imported ways. They carry the TIGER tags. I'm sure they could be verified as having come from the TIGER import. They were no-doubt the result of having split an existing TIGER way. In this case, why is it not sufficient to see the TIGER tags on the way to consider it blessed along with all the other TIGER ways? Especially when tagged afterwards by accepting mappers with sources as above? 8) Repeat step 7 for all bad ways (or points) in the list of data loss that License Problems displays. I'd like to suggest step 8.5: Run the OSM validator. It will find all the intersections that were missed, and probably a bunch of other problems that may or may not have pre-existed. 9) Upload your re-mapping efforts. So, can someone from the redaction squad comment on the logic being used and the questions above? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
At 2012-04-16 13:52, stevea wrote: At 2012-04-12 17:36, you wrote: I see excellent progress in California during the recent eight days of re-mapping. If you are an editing maniac... Can you comment on your process? I see very little real, coordinated info about tools, concrete solutions, or teamwork. As a formerly quite active SoCal mapper, I'm basically just dead in the water, wondering how much of my hard work has just been discarded (e.g. speed-limits, lanes, turn restrictions, source references, carefully aligned geometries, etc.) and whether to bother trying to get it back. I can't possibly be alone (?). I almost forgot: in step 7 of my previous message, the Delete step may inform you that you are deleting from a relation. This is especially true of motorways, which are often described with relations. If this is the case, go ahead and confirm the deletion from the relation, making note of WHICH relation(s) this element is a member of. Glad you mentioned that - it's something I've spent a lot of time on. Be sure to note the role of the object in the relation as well. In the case of turn restrictions, traffic-control, and housing relations, the role is as important as the object's presence, and will break the relation without it. So, we're left with: I can't even find any info on the redaction. What is the plan? Where is it now? How can I see what it's doing? Shouldn't there be a big, bold link to this kind of info on the wiki main page? Can someone involved comment? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
At 2012-04-16 14:06, Nathan Edgars II wrote: Or you can simply add odbl=clean if there's nothing ungood about the object (e.g. it was split from a TIGER way and the splitting is something you would have done anyway). Is this really sufficient? Can someone from the redaction squad comment? Can I protect/bless a way or node and prevent its redaction simply by (in good faith) adding this tag? Any ways that I have tagged with source=some_imagery;survey;image means I have aligned against imagery and personally photo-surveyed at least one street-name sign along it. It would certainly help to be able to just add odbl=clean to such ways that are complained about by the plugin instead of having to delete and re-add them, fix the intersections, and fix the relations. I'm also more likely to get it done, since it multiplies my productivity many times. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Truth about media hype in Microsoft lending big support and big dollars to OSM ?
At 2012-04-03 19:24, Russ Nelson wrote: Pieren writes: Where is the truth here ? Is the big support and big money the access of Bing aerial imagery ? Is that all ? Hey, that's enough for me. I LOVES the Bing aerial imagery. Microsoft is welcome to take all the credit for helping us that they want to take. I don't know about _that_, but I'll agree the Bing imagery _has_ been great and thank them for it. Nice to have (mostly) high-res, (mostly) well-aligned, well-served imagery as compared with previous MSRMaps, USGS, etc. solutions. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Remapping is good
At 2012-01-31 13:52, Nick Hocking wrote: This morning I decided to remap another street off Cypress Avenue L.A. I randomly choose Ariva Street and lo and behold the TIGER2011 overlay said that it was Arvia Street. TIGER is usually spot on with names and since a Bing search and Google maps/street view also agree about Arvia this street is now correctly named (courtesy of TIGER). Sorry I missed this earlier... 1. I've researched many hundreds of naming issues in southern Cal. I can't give you a specific percentage, but neither TIGER05 nor TIGER11 could be considered usually spot on, nor could most other sources. 2. AFAIK, you cannot use Google Maps/Earth as a source for naming, due to licensing. Same applies to Bing Maps, though we are specifically allowed use of their satellite imagery. Using them, anyway, would just be repeating an unknown source - not necessarily conducive to better map quality. 3. For LA County, there are great online sources of public records: 3a. Tract Maps: http://gis.dpw.lacounty.gov/website/SurveyRecord/tractMain.cfm and http://gis.dpw.lacounty.gov/landrecords/index.cfm?docType=TM and parcel maps: http://gis.dpw.lacounty.gov/website/SurveyRecord/parcelMain.cfm and http://gis.dpw.lacounty.gov/landrecords/index.cfm?docType=PM . These are official and should generally be given the most weight, particularly newer ones. Tract maps are preferable to parcel maps Streets that surround the subject tract or parcel will occasionally have mistakes in them. I tag objects based on these with source=LACDPW + source_ref=TR-ppp or MB-ppp for tract maps, or PMbbb-ppp for parcel maps. 3b. Assessor's maps: http://maps.assessor.lacounty.gov/mapping/viewer.asp Note that the basemap used in the viewer is not necessarily accurate, as it's sourced from a different place than the official assessor's maps. Find a property parcel along the street you want and use the (i)nfo tool to select it. Then, click on the Click here to view Assessor's Map, which will open a PDF map http://maps.assessor.lacounty.gov/mapping/viewAssessorMapPDF.asp?val=-ppp where is the 0-padded book number and ppp is the 0-padded page number (there are some exceptions to this format for very old areas). I tag objects based on these with source=LACA + source_ref=ABK-ppp or AM-ppp. 3c. You can check a parcel address against the USPS address database here: https://tools.usps.com/go/ZipLookupAction!input.action (not sure about legality here - it's arguable). 3d. Photo survey. A good old local observation of the street sign(s), hopefully with photo evidence can be helpful. I tag these source=survey;image + source_ref=AM909_DSCx (my picture number). Do note, though, that these are sometimes wrong (particularly street type). However, they at least warrant an alt_name tag until they are corrected. When I find incorrect signs, I generally research the responsible authority (incorporated city or county) and tell them about it. There are often instances where you have to decide which is correct, or you can't, in which case you should add an alt_name tag, all your source tags (semi-colon separated), and a note tag to explain the research done. Don't forget to remove the tiger:reviewed tag from ways you verify or edit, too. If people are going to spend an entire night armchair mapping, wouldn't it be great if they all remapped L.A. Maybe. As always, please look at the existing description, note, source and source_ref tags and/or history to see previous edits. It's not nice to incorrectly armchair-edit an object that someone else spent some time researching. Ways with tiger:reviewed tags (highlighted in various editors) are a good start, as they have usually not been edited. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remapping is good
At 2012-02-01 06:08, Nick Hocking wrote: Ok I've found a few more close typos Gassen not Glassen Correct. source=LACDPW;LACA + source_ref=PWFB1521-265;TR0044-020;ABK5456-016 Tropico not Tropica Correct. Tropico Way in LA 90065: source=LACDPW;LACA + source_ref=TR0726-039;ABK5464-006 Tropico Ave in Whittier: source=LACDPW;LACA + source_ref=TR0518-006;ABK8228-010 Lavell not lavel Correct. source=LACDPW;LACA + source_ref=PWFB1521-257;TR0023-102a;ABK5462-006 Pleasant View not Pleasent View Correct. source=LACDPW;LACA + source_ref=TR0012-064;ABK5454-023 Seymour not Seymore This one was interesting. See the notes at the bottom of the tract map for the name changes - the previous name was, in fact, Seymore. Name changes aren't always noted on these docs, so it's important to look at the dates, but it's nice when they are. source=LACDPW;LACA + source_ref=TR0016-042b;ABK5453-019 Arroyo Seco not Aroyo Seco Correct. source=LACDPW;LACA + source_ref=TR0049-071;ABK5446-022 Parrish not Parish It depends: In LA 90065, Parrish Ave: source=LACDPW;LACA + source_ref=PWFB1521-257;TR0101-001;ABK5462-008 In Burbank, Parish Pl: source=LACDPW;LACA + source_ref=PWFB1718-924;TR0128-041;ABK2444-009 Shilburn not Shelburn In LA 90065, Shelburn Ct is correct. source=LACDPW;LACA + source_ref=PWFB1422-333;TR0022-115b;ABK5451-008 Shelburne is used in two other places. I've have not fixed the Parrish/Lavell ones since there is something really wrong with either or both of OSM and TIGER. I believe that this area really needs another survey. I do have an unprocessed photo survey of the area I did in January and August 2010. Maybe if we ever get past the license change fixes... It would be great if TIGER2011 could be in one half of Frederik's compare tool and OSM in the other, however putting Google in the other half allows you to easily spot where there are potential spelling mistakes in the OSM data. In small areas, I've generated a unique list of names from an OSM file and then from TIGER or some county source and done a diff to identify the obvious ones. Of course, you have to re-abbreviate the OSM street types, and do various other manual things, but it's better than a visual compare. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Way with only one single node
At 2012-03-20 12:38, ThomasB wrote: I am wondering how a way with only one node can exist in the database. I have deleted it but how many still exist? http://www.openstreetmap.org/browse/way/154820504/history It is, indeed, deleted. See the upper right corner of the page. As to how it got to exist, I expect that it is up to editors (client software) to enforce that a way has more than one node, not the database itself. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] suburban superblocks that nobody wants to survey
At 2012-03-15 06:27, Mike N wrote: On 3/15/2012 8:52 AM, Hillsman, Edward wrote: In the interest of figuring out how to attract more people to participate in OSM, I'd like to see some more discussion of this. Is it generally true that people who work on OSM don't like to map subdivisions? And, if so, why? Because these are home to so many people in the US, it raises a question about the viability of strategies that suggest people start in OSM by mapping their own neighborhoods. I don't know anything about this specifically. It's interesting that not a single person in those 120 subdivisions was interested in mapping their own subdivision. Assuming we're talking about the US, not really surprising. I've mapped hundreds of subdivisions in southern Cal. In particular, dozens of them were not on the map at all, having been developed after TIGER's 2005 source date. Some were not even on Google Maps, so you'd think someone out there other than me would have wanted to map them. I have done some onsite surveys of smaller subdivisions (100-400 homes), and can set this up with a camera, video cam, and bike to collect quite a lot of information in a single visit, and the end result is streets with lanes, speed limits, one ways, and house numbers. Yup - me too, with a car, GPS, and a digital camera. In this area, since no one else is participating[1], it's just a practical matter to create the base new subdivision information from TIGER since the local governments don't freely give this information. The only followup surveys are quick to clarify obvious errors in the TIGER data. The subdivision plat idea is new to me, but I'm not sure where I'd find them. I've recently done this when I see an area that really is untouched. I first make sure that all the ways are the original TIGER ways (tiger:cfcc=* ((version:1 user:DaveHansenTiger) | (version:2 user:balrog-kun))), remove them, then convert and transplant in new TIGER2011 data, connecting it to existing ways at the borders. BTW, many (most IME) county governments have at least some data available for free. Assessor's maps are generally more available, though keep in mind that they are less authoritative on naming than tract/parcel maps because the assessor's role is more related to the land parcels than the streets between them. Tract/parcel maps, records of surveys, roadbooks, etc. are generally available from the planning and/or public works departments. While they are usually filed with the county recorder, that avenue is usually not free. All it takes is a little digging. If you run into a fee-required situation, don't be afraid to ask for a waiver, describing OSM and your need to use them as a reference. That's worked for me. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno has no primary roads
At 2012-02-21 10:40, Martijn van Exel wrote: On Tue, Feb 14, 2012 at 1:17 PM, Dave Hansen d...@sr71.net wrote: On 02/13/2012 05:19 PM, Nathan Edgars II wrote: It could just as easily be local mapping gone awry, by a local who thinks only state highways should be primary. The TIGER import would not have included any primaries, since there are no U.S. Highways in Fresno (though any such would be motorway). Here were the a2* mappings from the original import, fwiw: This seems to have been taken from https://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map What annoys me about that page (a lot, actually) is that there is no clarity as to whether this is the *actual* mapping used. There does not seem to be a direct correlation between the original tiger:cfcc values and the highway=* tag any more. Some roads were (properly) promoted to secondary since the original import. Some of those should be promoted further (to primary). I wouldn't focus so much on those original values, or what was originally done at import, since the TIGER classifications are known to be incorrect as compared with local knowledge and official definitions by city planners. Did you see my previous post? I provided a link to the planning data that describe the official planning categories and how I would map them to OSM. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What is a dual carriageway?
At 2012-01-15 09:45, Martijn van Exel wrote: I only map two separate ways when there's a median you can't cross, so the two directions are physically separate. By that rationale, it should be one way feature. I am curious if other mappers use the same convention. I do. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Rendering not happening at lower zooms
I've been doing some work here: http://www.openstreetmap.org/?lat=35.7216lon=-117.3273zoom=12layers=M , which is being rendered in zooms 13 and higher, but not at 12 or below. Most of the water feature shown by this link was removed a few days ago. When should it be rendered? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rendering not happening at lower zooms
At 2012-02-20 01:40, Nathan Edgars II wrote: On 2/20/2012 4:11 AM, Alan Mintz wrote: I've been doing some work here: http://www.openstreetmap.org/?lat=35.7216lon=-117.3273zoom=12layers=M , which is being rendered in zooms 13 and higher, but not at 12 or below. Most of the water feature shown by this link was removed a few days ago. When should it be rendered? Mark it dirty: http://wiki.openstreetmap.org/wiki/Slippy_Map#Mapnik_tile_rendering It's been this way for years. Thanks. I thought it was sufficient to attempt to view the tile and it would then see that it is dirty and add it to the queue. The must be more than 7 days old I did not recall, and explains the problem. Unless I missed it, there is at least one more description of the process on the wiki, which I read yesterday, which does not mention this. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tracking Deleted Streets and Comparison Tools
At 2012-02-18 16:03, Humphries, Grant wrote: I am attempting to track deleted streets and other changes that have significant effects on routing between versions of OSM data that are approximately one and two months apart ... the purpose of this effort is to ensure the integrity of the data each time we update, which happens every several weeks. How about: move along each way, printing a list of intersections (nodes that are shared with other ways) as pairs of names. Diff this against the new version to see where changes are. If you want to include changes in distance, include the intersection coordinates. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-01-15 05:35, Mike N wrote: On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. I hope there is no such bot being contemplated again. The last one created lots of issues. In any case, a tag shouldn't be necessary - if the name has been edited by a human, it should not be updated by a bot, or even another human unless they are willing to prove their edit. I've edited thousands of names based on photo surveys and official record research and wouldn't want that high-quality data corrupted. My experience is that TIGER is generally of poor quality with regard to names, and is actually getting worse. I routinely see streets that are made up of multiple segments where the spelling or suffix is not consistent among them. Some of these were even correct in the original TIGER05 import, and were corrupted since by a TIGER editor! -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remapping tips
At 2012-02-06 16:19, Paul Johnson wrote:
On Mon, 2012-02-06 at 17:14 -0600, Martijn van Exel wrote:
On Mon, Feb 6, 2012 at 5:06 PM, Nick Hocking nick.hock...@gmail.com
wrote:
[..]and copy in the TIGER 2011 name from the TMS overlay (remembering
to un-abreviate as you go).
As a reminder: the JOSM URL for that is
http://{switch:a,b,c}.tile.openstreetmap.us/tiger2011_roads/{zoom}/{x}/{y}.png
Some roads are (unfortunately) glued to landuse polygons. For these
you need to unglue first to make room for the road replacement. These
take a lot more time but, hopefully, there are not too many of these.
That's really bad practice IMO, but I find it practised here in Salt
Lake too. Quick way to unglue: Select the way, shift-select the glued
point(s), press g.
Ideally, these should be shifted to the border of the land use, rather
than another location within the right of way.
Exactly. As a technical matter, in almost all cases of a public roads in
the US, if you look at the tract map, you will see a permanent dedication
of an easement/right-of-way for the road, and that land cannot be built on.
For the most part, these ROWs are even wider than the road itself has been
built on. The residential and commercial landuse ways should definitely
extend no further than the sidewalk in this vast majority of the scenarios.
Even if it were possible for someone to build in the middle of a street,
unless they actually have done so, it shouldn't be mapped that way, since
we aim to map what we see now, not duplicate a zoning map of what could be.
--
Alan Mintz alan_mintz+...@earthlink.net
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2011 Road Tiles
At 2012-01-15 10:11, Ian Dees wrote: In order to assist with road name checking I've set up a Mapnik layer rendering from TIGER 2011 ROADS data. I also stumbled across the fact that the Census is making some of TIGER available as a WMS, too: http://wiki.openstreetmap.org/wiki/TIGER_2011#WMS As I said earlier, one should not necessarily use TIGER11 to correct earlier TIGER05 names when the two differ. Positioning has improved tremendously in urban and sub-urban areas, but I'm finding lots of naming discrepancies. Better quality will result if we verify from additional sources, like those available from many counties. Note that the Census's BAS maps seem to be from the same source database as TIGER, though maybe extracted at different times. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shootout in Vegas
At 2012-01-18 13:43, Nick Hocking wrote: http://www.openstreetmap.org/?lat=35.996927lon=-114.925865zoom=18layers=M TIGER 2011, google maps, and some other sources show the intersection as Shootout Place and Cattle Ranch Place. However TIGER 2010 and Google Streetview indicate the inersection is between Gold Camp Street and Cattle Ranch Place. I have put TIGER 2011 into OSM. I'm seeing something different than you are. TIGER11 shows the intersection at 35.9967094, -114.9276717 is between Cattle Ranch Place and Gold Camp Street. Gold Camp Street (TLID 20213) heads ~NE for ~40m and then turns ~N (as TLID 20215) at the intersection with Shootout Place at 35.9969776, -114.9273722. Using GISMO (http://gisgate.co.clark.nv.us/openweb/), we can look at other official sources. The assessor's map (179-34-5), as expected, doesn't show anything conclusive, since there are no parcels on this short street. Digging further, in PL105-70 page 2 (http://gisgate.co.clark.nv.us/assessor/webimages/default.asp), the segment is unlabeled. Based on TIGER11, I changed it back to Gold Camp. If one were able to use Google's Street View as a source (which we are not!), one could just make out that the street sign at the first intersection looks more like Gold Camp than Shootout. ... [time passes] I missed a detail in PL105-70. On page 5, there are details of the corners in question, clearly showing the short segment as being named Shootout Place. Given that this is the only official record, I would name it as such (and did). Someone should verify the signage, which may be incorrect. FWIW, after working on thousands of similar intersections, I would think it more likely to be named Shootout than Gold Camp, given the geometry. Also just South of this, it appears that Pistol Perry Parkway is gated. Looks gated to me too. PL106-61 also reserves that and other streets within as private streets, which generally means it's a gated community. Bing imagery is not conclusive so if a real mapper could verify this, that would be great. Nick ___ 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
Re: [Talk-us] TIGER 2011 Road Tiles
At 2012-02-17 06:35, Toby Murray wrote: On Fri, Feb 17, 2012 at 7:14 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: Better quality will result if we verify from additional sources, like those available from many counties. The best quality will result if we grab a GPS unit and a camera and GO there ourselves. Just sayin' :) Of course. I've spent a great deal of money and time doing so. But again, it only proves what is signed. I've been responsible for getting bad signage replaced when I saw conflicts between it and the official record. I'd welcome financial support for continued field surveys if anyone knows of a source. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shootout in Vegas
Found some more evidence. In GISMO, if you zoom far enough in, the segment in question gets a label - Shootout Pl. I also found street centerlines at http://gisgate.co.clark.nv.us/gismo/freedataNEW.htm in crscl-shp.zip (streets_l dated 2012-01-27) which confirms the name Shootout Place. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-02-17 12:50, Mike N wrote: On 2/17/2012 3:02 AM, Alan Mintz wrote: if the name has been edited by a human, it should not be updated by a bot, or even another human unless they are willing to prove their edit. I've edited thousands of names based on photo surveys and official record research and wouldn't want that high-quality data corrupted. For myself, I don't know how to determine what the correct name would be ... if it doesn't match the street sign, I'd be inclined to change it to agree with the sign, unless there's a 'note' tag to other mappers. Similarly, an 'anti-abbreviation-bot' tag would prevent bots from undoing your research. When I edit, I populate the source and source_ref with the appropriate values to cite my source(s) and remove the tiger:reviewed tag if present. The fact that the object has been edited by a human should be sufficient to keep the bot from touching it. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-02-17 13:41, TC Haddad wrote: Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. +1, though there is significant argument on both sides, and the non-abbreviators have so far managed to keep the status quo. For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) really detract from the experience of using osm extracts on handheld GPS. All the streets in an area of interest end up looking like they have the same name because all that fits on the street segments is the first word of the expanded quadrant label and not the real part of the name. So NE Tillamook and NE Hancock both just label as Northeast... and that is separate from the issue that people don't actually write addresses here as Northeast Tillamook. Theoretically, the consumers of the data (renderers, etc.) are supposed to do the work of re-abbreviating where necessary, but that seems to have gotten lost in the design of some/most of them. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fresno has no primary roads
At 2012-02-13 15:21, you wrote: I've never been to Fresno, but I can't believe there would not be a single primary road there. Still, that is the Truth According To OSM[1] I find that most areas where there has been little manual editing of the TIGER import will have roads that are generally under-classified (i.e. mostly highway=residential, with few if any higher-classed roads). I don't know where TIGER's original classifications came from, but they don't seem to match common sense very well or even documented sources, like city general plans. FWIW, TIGER 2011 is no better, and getting even worse in some other respects, like naming errors. ... A little research yielded this GP circulation map: http://www.fresno.gov/NR/rdonlyres/5EA02A61-FCDE-41C2-B707-DDED0E820677/0/GeneralPlancirculation.pdf (it's not clear if this 2025 map is projected or current - more research). It seems to have five classifications above residential/local (ignoring the scenic modifier), which I would map as follows: Collector - tertiary Arterial - secondary Super Arterial - primary Expressway - primary Freeway - motorway Closer inspection of imagery or a survey might lead me to downgrade a motorway or upgrade a primary to trunk, based on features like on/offramps, etc. CA-99 used to have a lot of areas that were more trunk-like than freeway, but it looks like it's been built up to freeway standards in this area at least. The Streets download listed here: http://www.fresno.gov/Government/DepartmentDirectory/InformationServices/GIS/Layers.htm has GPCIRC values which seems to correlate with the values shown in the map with a little work (I can't find a data dictionary, but the coordinate system seems to be CCS Zone 04, US Feet). Who knows more about this situation? Are there any local mappers on this list who can shed their light on this? Is this armchair mapping gone awry? Someone who doesn't like red? [1] http://www.openstreetmap.org/?lat=36.7974lon=-119.7218zoom=12layers=M -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ 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
Re: [Talk-us] Medians and reverts
At 2011-12-21 12:59, Paul Johnson wrote: On Wed, Dec 21, 2011 at 01:51:37PM -0500, Richard Weait wrote: On Wed, Dec 21, 2011 at 12:45 PM, Paul Johnson ba...@ursamundi.org wrote: I'm looking through a situation that is clearly frustrating data consumers Are these consumers entering HOV lanes without direction from the nav system then expecting the nav system to tell them how to get out of the HOV lane? In some cases, yes. In others, being directed to take ramps only available from the HOV lane. All of which are good reasons to draw HOV lanes as separate ways. I've also sometimes drawn the HOV parts of onramps separately, since it is the cleanest way to tag different access restrictions, number of lanes, traffic control devices, etc. What is the alternative? Some kind of tagging scheme that refers to individual lanes within a single way? That's already kind of annoying when trying to accurately map bike lanes (because they don't exactly follow the car lanes physically or schematically). -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Announcement: Address Improvement project
At 2011-10-04 18:38, Ian Dees wrote: When I use addr:street I put the entire street's name in the field. Breaking apart that street name into pieces is the job of other tags, I would imagine. I proposed, and have widely used addr:street_direction_prefix for the cardinal direction of addr:housenumber along addr:street. I've also used addr:suite when needed. Example 1: when there is one Main Street that runs predominantly N/S, 123 North Main Street is tagged: addr:housenumber=123 addr:street_direction_prefix=N addr:street=Main Street Example 2: When there are two separate Vermont Avenues that run predominantly N/S and parallel to each other, 123 West Vermont Avenue is tagged: addr:housenumber=123 addr:street=West Vermont Avenue In this particular case in Los Angeles, the Vermont Avenue right-of-way was split to put a rail system down the middle, creating a southbound West Vermont Avenue and a northbound East Vermont Avenue. I'd like to see some kind of indicator to show that the second case is correct (i.e. the direction is really part of the street name) instead of just being an instance that hasn't been properly analyzed yet. I had proposed making the addr:street tag contain the full prefix+root+type+suffix and then using addr:street_* tags for the individual components, the presence of any of which would indicate that the name had been properly analyzed. I understand the arguments that this can be complicated to explain/use/enforce. Not sure what to do about that. I don't think it's rocket science. There are days when I think we should expect more. Then again, on days when I can't read 3 professional 300-word news stories without finding 10 mistakes... -- Alan Mintz alan_mintz+...@earthlink.net ___ 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
At 2011-08-20 09:46, Nathan Edgars II wrote: On 8/20/2011 12:42 PM, Metcalf, Calvin (DOT) wrote: It doesn't matter if a state like MA uses SR internally we just use that because we deal with only one states routes. Postal code prefixes for all routes makes the most sense. My understanding was that there are two options for California SR-60: 1) network=US:CA + ref=60 2) ref=CA 60 the second one, being older, is what we've used for the most part. So how do you distinguish California from Canada? Or Delaware from Germany? Assume that, lacking a network tag, the ref tag is composed of state # or I # or US #. In other countries, they presumably also have adopted their own standards for the format of the ref tag. And do you support putting an abbreviation of the county name in the ref tag for a county route? Or are those fine with the ambiguous CR? I don't think CR is ambiguous, since there is no state by that name. I also favor (and use) adding the network=US:state:county to these. I know that in California, the county roads are actually unique throughout the state, so the county is not required, but it is present on the signage, so I make note of it in this way. -- Alan Mintz alan_mintz+...@earthlink.net ___ 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
At 2011-08-20 12:34, Nathan Edgars II wrote: On 8/20/2011 3:29 PM, Val Kartchner wrote: Because some states officially designate the road as SR-26, for instance. I'd say most states do. That doesn't mean, though, we have to copy it. The SR is assumed. Not to mention states like Texas, which have, for example: State Highway (SH) 121 Loop 12 Spur 408 Beltway 8 Farm to Market Road (FM) 1960 Park Road (PR) 27 and probably a few more types. It seems like each state has a State Route / State Highway class of road, and a ton of existing tagging with the aforementioned: network=US:ST ref=# or ref=ST # For FM 1960, I'd use: network=US:TX ref=FM 1960 or ref=TX FM 1960 These should require no extra work in parsing - the additional class just becomes part of the route # for display. If a particular renderer has the right shields for these classes in each state, it can parse out the route class. Standard abbreviations for the route classes should be listed in the wiki page for the particular state highway tagging. -- Alan Mintz alan_mintz+...@earthlink.net ___ 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
At 2011-08-21 06:56, Henk Hoff wrote: A suggestion: - ... When the road is part of multiple routes, the main route is used. That could be: ** a higher classification prevails (US over state) ** the continuous route prevails (if route x uses part of route y to get to it's next section, then route y is used). ** the number closed to 0 prevails I disagree. The semi-colon delimiter should be used. I doubt people could remember which rule to apply, and I don't agree it should be applied anyway, as for any particular roadway, the name by which it is colloquially known is inconsistent. CA example: I-215 shares routing with SR-60 for a few miles. People in the area still consider it SR-60. It is tagged ref=CA 60;I 215. SR-79 shares routing with I-15 for a few miles. People in the area still consider it I-15. It is tagged ref=I 15;CA 79. These actually conform with the second rule above (and the third, but that's entirely coincidental), but I'm sure I can find counter-examples. -- Alan Mintz alan_mintz+...@earthlink.net ___ 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
At 2011-08-21 10:29, Nathan Edgars II wrote: On 8/21/2011 9:21 AM, Alan Mintz wrote: My understanding was that there are two options for California SR-60: 1) network=US:CA + ref=60 2) ref=CA 60 SR 60 is a good example, since it overlaps I-215 in Riverside. The network tag won't work here, since it needs to be both US:I and US:CA. Shared routes use semi-colons, like any other multi-use object. ref=CA 60;I 215 or network=US:CA;US:I ref=60;215 -- Alan Mintz alan_mintz+...@earthlink.net ___ 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
At 2011-08-21 10:57, Henk Hoff wrote: For every rule we can find exceptions. In this case, I will guess the exceptions (shared routes) are less than 5% of the ways. The basic idea behind the decision-tree was: use the most important / most logical route for the way-ref tag. If you know the important one, make it the first value in the series. Putting every single route-label in the ref-tag is not a good idea. Why? I guess that 95% have only one, 4% have two, and the remaining 1% might have more (I seem to remember seeing 4 in the midwest somewhere). Remember we're only talking about the road routes themselves. Bike routes, etc. go in their own tags. If you want to identify a whole route, use a relation. Based on the relations (a way is part of) a routing engine could then identify under which other route numbers this road is also known by. As someone pointed out, once you put them in a relation, the tags on the ways become duplicative. While this is generally bad database design, it's also true that many consumers don't deal with relations, and so we need the duplication and the problems that go with it. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Data reconciliation. Removing CT/ODbL declined users.
At 2011-07-20 09:49, Richard Weait wrote: The License Working Group takes the position that it is now appropriate to begin reconciling the data touched by users who have explicitly declined CT/ODbL. ... ...don't remove non-compliant data unless you are replacing it;... Is there a clear definition of what non-compliant data is? Is it (a) based on the last user to edit an object, or (b) is an objected tainted if it was touched at any point by a declining user? If (b), must the object be removed and then re-created (with a different object ID)? And why is that object conceptually any different than (a)? Is a way tainted if any of the nodes it references is tainted? Is a relation tainted if any of its members (or its members' members, etc.) are tainted? I'm sure there is a long discussion of these issues somewhere, but a concise answer to these specific questions seems necessary in order to know how to reconcile. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Which county next?
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
Re: [Talk-us] Which county next?
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
Re: [Talk-us] updated critical address file for US - 25 April 2011
At 2011-04-25 14:02, deb t wrote: MapQuest is providing critical address files on an ongoing basis to the OSM community that contain user-provided latitude and longitude locations across the world. Our users have provided these exact locations to us so that they could be mapped correctly on our MapQuest maps. More information can be found on our wiki page: http://wiki.openstreetmap.org/wiki/MapQuest/Critical_Addresses . All update files are in addition to the main country file and any other update file posted. Today, we added one new update file for the US: US: http://www.mqdemo.com/antfarm/criticaladdressfile/critical_address_file-US_update-25April2011.csv Please don't import these without verifying against your own local knowledge or other sources. Experience is that they are poorly geo-referenced and/or have other problems. For example, in this file, the only one in my area is wrong: 13095 Jamboree Road,US,CA,Tustin,92782,33747885,-117767370 is actually about 1.6 *miles* southwest of that point. Is it possible that there is something wrong with MapQuest's process that causes users to misplace things so much? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] OpenStreetMap License Change Phase 3 Pre-Announcement
At 2011-04-12 11:56, Michael Collinson wrote: This is to let you know the license change process is moving to Phase 3 [1] very shortly. What exactly will be done with the existing data, and when? Understanding what happens to objects and their parents/siblings/children based on the license acceptance of the original creator/intermediate editors/last editor is key to deciding whether I should accept or decline. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] School bus routes?
At 2011-04-10 09:42, Nathan Edgars II wrote: I came across a relation for a school bus: http://www.openstreetmap.org/browse/relation/239393 Isn't this a little too much detail for OSM? A single relation? Really? We map lots of private-access things, like driveways and access roads, private clubs, etc. As far as volume, fighting with limits caused by import of tens of thousands of individual non-streams in the desert, landuse shapes that were over-digitized by an order of magnitude, individual trees, etc. all seem more realistic things to focus on limiting, no? Use of OSM by schools is a great use of both their and our resources. The only note I'd be sending the user is to encourage them to import more of their bus routes and show others how to do so. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] School bus routes?
At 2011-04-10 12:43, Richard Welty wrote: On 4/10/11 1:39 PM, Alan Mintz wrote: At 2011-04-10 09:42, Nathan Edgars II wrote: I came across a relation for a school bus: http://www.openstreetmap.org/browse/relation/239393 Isn't this a little too much detail for OSM? A single relation? Really? We map lots of private-access things, like driveways and access roads, private clubs, etc. As far as volume, fighting with limits caused by import of tens of thousands of individual non-streams in the desert, landuse shapes that were over-digitized by an order of magnitude, individual trees, etc. all seem more realistic things to focus on limiting, no? Use of OSM by schools is a great use of both their and our resources. The only note I'd be sending the user is to encourage them to import more of their bus routes and show others how to do so. but they do vary from year to year. As do commercial bus routes, at least based on the number of stickers with changes on them I see on signage around here. In fact, I'll bet that's on the rise as more/easy analysis of passenger counts is available to operators through integration with GIS. i worry about importing such data then failing to maintain it. it's very subject to bit rot. At the yearly level, true of any temporal data that we enthusiastically map, like tenants of strip malls*, business opening hours, speed limits, and turn restrictions. It just seems like OSM is well-suited for use by schools. They have to maintain data like bus routes, campus maps, etc., it's to both their and their communities' advantage to make it free and accessible, and it spreads the gospel of OSM. *The stats on new small business failures are truly depressing. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] note to folks doing mapping based on aerial imagery
At 2011-04-10 15:39, Richard Welty wrote: On 4/10/11 1:50 PM, Alan Mintz wrote: At 2011-04-10 08:16, Richard Welty wrote: please don't go overboard mapping areas from imagery where you can't do ground surveys, particularly where there are clearly local mappers working. ...and please try to make this obvious to others, particularly by removing the tiger:reviewed=no tag on TIGER import ways. This causes them to render differently in most editors, and are an indicator that someone is tending to the area. unfortunately, this isn't terribly effective. i removed the reviewed tags long before the area in question got fixed twice. i have comment tags on the relevant ways now, but i'm going to change comment to README to make it more obvious. Hmmm. I've been using http://wiki.openstreetmap.org/wiki/Key:note for such comments. Any idea which of them render by default in the various editors (and not in non-debug renderers)? My JOSM config is non-standard in this regard (mappaint.nameOrder), so I can't tell easily. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] County road network relations (was: REF tags for State Highways on ways)
At 2011-04-10 14:00, Kristian M Zoerhoff wrote: What's the consensus for county roads in the US? I don't know what the consensus is. County roads in California are of the form [A-Z][0-9][0-9]. I tag Orange County route S18 as: network=US:CA:Orange + ref=CR S18 -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-04-09 11:02, Paul Johnson wrote: On 04/08/2011 11:47 AM, Alan Mintz wrote: I would omit the hyphen as CA 247 for consistency sake. I'm not sure which post this referred to. My understanding of the discussion on this subject was that people agree that the hyphen is necessary to join the parts of a highway number together to avoid ambiguities, and because it normally appears that way in text. However, for some reason, it was agreed that only in the ref tag, the hyphen would be replaced with a space. Everywhere else, though, it retains the hyphen. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-04-07 13:47, Mike N wrote: On 4/7/2011 4:09 PM, Alan Mintz wrote: Case 2. Very occasionally, there will be more than one street name shown, usually when the ramp ends at or near a point where a street changes name. Use semicolons to place multiple values in the exit_to and exit_to_dir tags. e.g.: Exit 73 / Diamond Drive / Railroad Canyon Road is tagged ref=73 + exit_to=Diamond Drive;Railroad Canyon Road Exit 183 / SR-247 South / Barstow Road is tagged ref=183 + exit_to=CA-247;Barstow Road + exit_dir=South; Does exit direction refer to the compass direction of the intersecting road, or the signed direction, and if so which road in the list? Compass direction of the road, usually for intersections with primary or higher category roads where there are multiple ramps to reduce intersections (e.g. cloverleafs). Sign: I77 North; US 44 East; NC 56 East; Charlotte; Rock Hill; York Assuming that Charlotte, Rock Hill, and York were aligned with I77, US44, and NC56, respectively on the sign: exit_to=I-77 North;US-44 East;NC-56 East towards=Charlotte;Rock Hill;York OR exit_to_root=I-77;US-44;NC-56 exit_to_dir=North;East;East towards=Charlotte;Rock Hill;York (See note [0]) So someone has to parse the sign to be able to properly enter the information? And I'm still not clear on the benefit of having it separated if the first thing the data consumer does is string it back together. Not all consumers are for the purpose of navigation or map rendering. It might be useful, for example, to be able to query select * from CA-60 exit nodes where exit_to_root=Rosemead Blvd to get both ramps from CA-60 to Rosemead Blvd, instead of having to use 'exit_to like Rosemead Blvd%'. [0]: You may have been alluding to some ambiguities in the way ; can be interpreted. Here's what I've done when the number of values in one tag is not the same as the number of values in another related tag. I'm hoping that consumers follow suit: - Each value consists of fields that are separated by semicolons. - Empty fields in the beginning or middle of the value are indicated by just the separator (semicolon). This also means that you use a trailing ';' to indicate that the last field in a value is empty. - If valueA and valueB are related, you parse them from left to right to get the correct A/B pairs. If you run out of fields in one before the other, the last value is repeated for the one that is short - otherwise the user should have just used empty fields to indicate there were no values there. e.g.: A-B pairs 1-2, 3-4, 5-nothing, 7-8, 9-10, 11-10, and 12-10 would be encoded as: A=1;3;5;7;9;11;12 B=2;4;;8;10 If you add another pair 13-14 to the end, you would have to encode it: A=1;3;5;7;9;11;12;13 B=2;4;;8;10;10;10;14 Yes, this can be complicated. If the user chooses not to use the unequal count feature, just ensure you put the same number of fields in each value, repeating or using an empty field as necessary. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-04-08 09:55, Nathan Edgars II wrote: On 4/8/2011 12:47 PM, Alan Mintz wrote: At 2011-04-07 13:31, Nathan Edgars II wrote: On 4/7/2011 4:09 PM, Alan Mintz wrote: Exit 183 / SR-247 South / Barstow Road is tagged ref=183 + exit_to=CA-247;Barstow Road + exit_dir=South; Does anyone have examples of places where my suggested model does not work? It's not backwards-compatible with anything that uses exit_to. To get the text of the sign you have to piece together the exit_to and exit_to_dir fields. It's the way it was done with the street name split a while back, though I acknowledge that it isn't an identical situation, since we ultimately decided the direction was not part of the street name. In this case, the direction is an important part. It's not even close to identical. Ack'd, as I wrote. It's very rare to have two parallel streets with the same name except for a different directional prefix (and in those cases the directional prefix should be part of the name). Agreed, though I can think of two immediately, one of which is just a couple miles from me (North and South Mainstreet), and the other in LA (East and West Vermont St. running N/S). In the direction prefix discussion, all agreed that the directions in these _are_ part of the name, and should/would not be separated out. They should not be separated in this case either. On the other hand, it's very common to have two consecutive exits for each direction of a road. The question is still what benefit there would be to splitting it. I gave an admittedly weak example in my last response to Mike N. My point is still that there does not necessarily have to be an existing use case to support modeling the data in this way. It's part of an experienced DBA's skillset to be able to guess at what might be needed in the future when modeling data today to reduce rework in the future. In the OSM environment, where there is no formal schema, versioning, practices to sync consumers and providers on the same spec, etc., it's particularly heinous to have to re-work things later. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-04-07 22:57, James Mast wrote: You know guys, we should also figure out right here and now how to deal with left exits at Interstate splits where both ways are motorways. Here's such an example: http://www.openstreetmap.org/?lat=36.49591lon=-80.74103zoom=16layers=M It's the I-77/I-74 split in NC. I-74 splits off to the left using an I-77 exit number (Exit #101). Something like this would need an extra tag on the node where the highways split. Looks mostly right as is, except I capitalize East (and want it in its own tag), hyphenate I-74 (because it is in a name field, not a ref), and would move the destinations to the towards tag: exit_to=I-74 East towards=Mount Airy / Winston Salem ref=101 OR exit_to_root=I-74 exit_to_dir=East towards=Mount Airy / Winston Salem ref=101 Because it is the start of the motorway, I see no reason to call it a motorway_link. I just continue the new motorway right up to the motorway_junction. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-03-28 12:19, Ian Dees wrote: In this picture: http://www.nomadchallenge.com/wp-content/uploads/2008/08/likelike-highway-honolulu.jpg What is the proposed tag for the highway=motorway_junction node? Are we tagging the node with exactly what is on the sign or are we looking down the road and coming up with text on our own? Because Likelike Hwy. is the name of HI-63, I would like to tag: ref=20A exit_to_root=Likelike Highway (HI-63) exit_to_dir=North -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Interstate exit junction exit_to tag
At 2011-04-08 14:06, Mike N wrote: On 4/8/2011 1:16 PM, Alan Mintz wrote: I would not be averse to something like: exit_to=CA-247 South OR exit_to_root=CA-247 exit_to_dir=South Consumers that have evolved can use the second form if it is found, or the first if it is not. Older consumers can use the first form. Users that choose not to use the second form can use the first form and it will work with both old and new consumers. The point of the most recent change was standardization - consumers should not need to code 2 routines to handle both forms. One if does not two routines make. Our tagging guides should be as simple as possible. Agreed. sarcasmLike turn restriction relations. And destination sign relations. And traffic camera relations./sarcasm There is already a good 1 page on motorway_junction. If a non-programmer were to try to enter their information and saw a full second page just to cover parsing rules, they would simply abandon their efforts as too complicated. If that were the case, I'd agree that a better solution should be found. Is it a full page? Not even close. Perhaps you were referring to my departure from the thread regarding semicolons, which is not at all specific to this group of tags? (That already happens too often today with the existing OSM guidelines) That is hardly the only reason. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] update to MQ critical address file for US, CA and GB (4Apr2011)
Just a reminder - please don't blindly import these - they have been shown to be of limited accuracy. Example from the current file: 18175 Chatsworth Avenue,US,CA,Granada Hills,91344,34.263971,-118.528055 a. It's actually Chatsworth Street, not Avenue, according to LA County assessor's map 2715-012, Parcel Map 161-009, and USPS b. The location given is, at best, over 250 ft from the driveway of, and on the other side of the street from, the actual location of this self-storage business. Also, note that many points have 3 entries, each with varying amounts of abbreviation. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
