Re: [Talk-us] Extremely long Amtrak route relations / coastline v. water
[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] Brian M. Sperlongano wrote: > It seems that we are increasingly doing things to simplify the > model because certain tooling can't handle the real level of > complexity that exists in the real world. I'm in favor of fixing > the tooling rather than neutering the data. I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", though I fear I may be disappointed. More broadly, we need to nip this "oh just fix the tools" stuff in the bud. OSM optimises for the mapper, because mappers are our most valuable resource. That's how it's always been and that's how it should be. But that does not mean that volunteer tool authors should rewrite their tools to cope with the 0.1% case; nor that it is reasonable for mappers to make stuff ever more complex and expect developers to automatically fall in line; nor that any given map has a obligation to render this 0.1%, or indeed, anything that the map's creator doesn't want to render. The Tongass National Forest is not "in the real world", it is an artificial administrative construct drawn up on some bureaucrat's desk. It's not an actual forest where the boundaries represent a single contiguous mass of trees. Nothing is lost or "neutered" by mapping it as several relations (with a super-relation for completeness if you insist), just as nothing is lost by tagging Chesapeake Bay with the series of letters "c","o","a","s","t","l","i","n" and "e". Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
SteveA wrote: > With both of us in agreement about tag "proposed:route=bicycle" > (especially as it co-exists with "state=proposed") can we gain > some more consensus (here, soon?) allowing us to move closer towards > recommending in our wiki that we tag proposed USBRs with > "proposed:route=bicycle"? Honestly, please don't. state=proposed has been around since the very first days of route relations and everything supports it. proposed:route=bicycle is wordier and has no advantage other than some people appear to think tags with a colon in are automatically superior, because XML has namespaces and therefore we must too. Changing the tags will achieve nothing; will mean that data consumers have to support two schemes instead of one; and will needlessly break stuff. On the positive side, great to see all these USBRs going into OSM as ever! Richard cycle.travel ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trunk VS primary,
Eric H. Christensen wrote: > The routing engine should be able to take into account > the road surface It can and often does. Your problem there is that only 2% of highway= ways in the US are explicitly tagged with surface; probably only 30% are implicitly tagged; and sometimes the implicit stuff gets broken, like when people start retagging gravel roads as secondary without adding a surface tag. (Numbers are estimates but I think not far off.) > Any idea why trunk was established in the first place? It's a word from the UK road classification system, because OSM was invented in the UK. But the letters in the word aren't really important. OSM has five broad-brush motor-road tags (trunk, primary, secondary, tertiary, unclassified), plus special-case ones at either end of the hierarchy (motorway for limited-access high-speed roads, residential for roads with the main purpose of providing access to houses on that road). If you don't think you need five, you don't need to use all five. If you need more than five, you are free to use additional tags to supply extra nuance, as the Germans do with motorroad=yes. I would say that 15 years is probably more than enough time to decide what roads you're putting in what category, but hey, this is OSM. Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mapping rail trails
Minh Nguyen wrote: > As with the network tag on bus routes, what's important for both > network and cycle_network is that the route is intended to form > part of a coherent *network* (almost like a brand, but not quite). It's also useful for those of us writing routers, as it means we can avoid applying a route relation uplift in those states that send bike routes along entirely unsuitable state roads. (New York is a particular offender but there are others.) On my relationising travels, I spotted a couple of places where people had mapped a city cycle network as a single route relation, often with "System" in the title: Flagstaff Urban Trail System was one such. This is clearly wrong. As a quick fix I changed the relation tagging from type=route to type=network - which, interestingly, Waymarked Trails still renders: https://cycling.waymarkedtrails.org/#route?id=2815833 - and created relations for some of the longer routes. But really it needs all the routes to be broken out into individual relations and given a common cycle_network tag. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mapping rail trails
Kevin Kenny wrote: > And route relations are important for sites like Waymarked Trails - > it totally ignores walking and cycling routes that are not indicated > with relations, which is why I wind up doing routes for even > relatively trivial stuff like > https://www.openstreetmap.org/relation/4836600.(although > that certainly meets Richard's five-mile threshold). Ok. I've just finished a pass through CONUS relationising pretty much all the significant leisure trails I could find for which there weren't already route relations. HDYC is telling me that "recently" I've added 334 bike routes - I'm not sure what period that covers but it sounds about right. By and large I've tagged them with network=lcn - there's certainly a case for upgrading some to =rcn but I'll leave that to those with local knowledge. There's a bit of work still to do on smaller local trails that also form part of a longer route - e.g. parts of the Bay Trail, or the East Coast Greenway. It would be good to have a distinct C Canal Trail relation over and above the USBRS 50 relation, for example. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Mapping rail trails
Hi all, You might remember that back in March I wondered whether we could get access to the Rails-to-Trails Conservancy's data, which they've given to Google: https://lists.openstreetmap.org/pipermail/talk-us/2019-March/019266.html Helpful people on this list followed that up with RTC (thank you!). Finally the answer has come back and it's no. The data is apparently "free as in Google" - sadly RTC aren't interested in having their trails appear in basically every single cycling app which uses OSM data. (In completely unconnected news, I note that RTC currently sells "TrailLink Unlimited" mapping for $29.99/year.) I find this a great shame as someone who loves cycling rail-trails - mostly over here in the UK, but I've ridden a few in the US: we don't have any single structure as cool as the Walkway over the Hudson, so I had to do that when I was at SOTM-US a couple of years ago! So... let's do it ourselves. OSM was founded in 2004 on the principle of "if they won't give us the data, we'll make it ourselves" and that still holds true. I've started on making sure all rail-trails of a reasonable length (say, 5 miles upwards) are actually mapped in OSM, using route relations. Often the trails are in there as ways, but no relation has been created. Sometimes a trail has been extended on the ground from when it was originally mapped. Other times there'll be a trail relation for a longer route (e.g. a USBRS route) of which this forms part, but not for the named trail itself. If we get the basic trail data in OSM, so the trails show prominently in apps and other renderings, then that will encourage cyclists to use OSM and then add the detailed info (surface, facilities, trailheads, connecting paths etc.) that is best acquired by survey. I've had a quick blast through several states so far (AR, IA, ID, IN, MA, MD, ME, MT, NE, PA, RI, SD, WA, WV, WY, plus a little bit of work in CA and OH). I may of course have missed some trails. I've been creating route relations with route=bicycle, network=lcn, and an appropriate name tag: I'm not a great fan of making up abbreviations for the ref= tag but if that floats your boat, go for it. So why not have a go? It's easy work and you get to see the routes appear on http://cycling.waymarkedtrails.org pretty much instantly. (Obviously don't copy any information from RTC's website or similar. Most trails have their own websites: factual statements on those sites can almost certainly be used as fair use.) cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them
Mateusz Konieczny wrote: > Please comment no matter what you think about this idea! I will > not make the edit without a clear support so please comment if > you think that it is a good idea and if you think that it should > not be done. I think it's an excellent idea. I've deleted these nodes when I've encountered them during general TIGER fixup but there are a lot, and often in completely untenable locations. The other automated edits you're proposing would be better done by adding the keys to editor blacklists because the tags aren't actually harming anyone. But the data in this case is actively misleading (it breaks, for example, "nearest post office"-type searches) so should be deleted. Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Rails-to-Trails data
Hi all, I see that Rails-to-Trails Conservancy donated their GIS data to Google: https://www.railstotrails.org/our-work/trail-mapping-and-gis/ Anyone in the US fancy asking if they might do the same for OSM? Our coverage is good on the major trails (Katy Trail, Coeur d'Alenes, etc.), but often missing for smaller or less frequented trails, and I believe RTC have some metadata (surfaces etc.) it'd be good to have. Since most cycling apps and websites use OSM data it should be a win for RTC to have better data in OSM. I'm happy to approach them if no-one else does, but it'd probably be better coming from, you know, someone on the same continent. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Population during mandatory evacuations
Minh Nguyen wrote: > Following some discussion about this changeset in OSMUS > Slack [2], I started a discussion on the wiki about preferring > more stable population figures over supposition about > temporary circumstances. [3] It's roughly analogous to a situation we had a few months ago with road closures due to Hurricane Florence: https://twitter.com/richardf/status/1040931194999898114 I think the answer is that temporary situations need temporary (i.e. lifecycle-bounded) tagging. Tagging temporary situations with unbounded tags is ok for those browsing osm.org or another online slippy map with minutely updates, but not for anyone using offline maps, sites with less frequent updates, and so on. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Spartanburg County SC road centerlines import
Mike N. wrote: > As one who grew up in a rural area, a country road lined with 4 > houses in a mile would feel "residential" and I would tend to set > it as residential in OSM. That describes most of the rural parts > of this county also, except for roads that don't happen to have > a house. Absolutely, not disputing that - it's simply that tiger:reviewed=no is a good signifier that "the surface type on this road might not be what you'd expect", and for developed countries that's traditionally a paved surface for residential roads. As long as there's some way of discerning that, I'm happy. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Spartanburg County SC road centerlines import
Mike N. wrote:
> This is a proposed import of road centerlines for Spartanburg County
> SC, based on county GIS data. This will include a systematic review of
> all roads in the county and qualify to remove tiger:reviewed tags.
Looks good!
Browsing through the code and the wiki page, you have:
>else:
>if hwy != '':
>print ('Unknown highway type: ', hwy)
>tags['highway'] = 'residential'
and
> Add surface type as paved if it appears paved in imagery.
Could I suggest that you act cautiously wrt the tiger:reviewed tag in these
two cases?
If it's an "unknown highway type" it should probably remain as
tiger:reviewed=no. Likewise, if the surface isn't clear, then either
tiger:reviewed should continue to be =no, or there should be some other
tagging to indicate this (surface=unknown, or surface:reviewed=no, or
something).
cheers
Richard
--
Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Drop the tiger:reviewed tag from roads
Clifford Snow wrote: > I did learn from Toby Murray this morning that you can add > tiger:reviewed to the list of discarded tags in JOSM by going > to preferences->Advanced Preferences and adding > tiger:reviewed to tags.discardable. Then just reload > JOSM for the changed to be active. Just an additional data point: I use tiger:reviewed extensively in cycle.travel's mapping and routing to make sense of OSM in rural areas. Bike routing generally prefers minor roads with fewer cars (residential, unclassified, tertiary) and avoids major roads with many cars (primary, trunk, motorway). Bike routers will usually try and maximise the use of residential roads. Because TIGER class A41 was imported as highway=residential, and much of A41 is dirt tracks or worse, applying these routing weightings to the US would mean that the router seeks out what are often unrideable routes. tiger:reviewed is a useful signifier that someone has actually looked at a residential road and verified that it is a residential road as we understand it in OSM. So, for the sake of us cyclists, please don't clear tiger:reviewed if you haven't reviewed a road! (In urban areas I do agree that tiger:reviewed is often now worthless.) cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Gravel roads and surface tags in the US
Jack Burke wrote: > Keep in mind that OSM apparently uses "compacted" to refer to > macadamized roads, which is a specific process for building roads. surface=compacted in OSM, following British English usage, is traditionally as described on pages 18-20 of this document: https://www.sustrans.org.uk/sites/default/files/images/files/migrated-pdfs/Technical%20Note%208%20-%20Path%20surfaces(1).pdf "Self-binding gravel paths are versions of the standard limestone dust surface... The material is spread and levelled using a paving machine whilst damp/moist and then compacted using a roller or vibrating plate. The material 'sets' when dry, but not to the same extent as would a concrete or bitmac. The surface remains loose-ish and dusty" From Toby's original posting, I'd describe the first image as surface=gravel, since it doesn't appear to have been compacted with a roller. The second is probably =fine_gravel, perhaps =compacted. I'd ignore the wiki because the wiki, to borrow a phrase, sucks rocks. Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Edit war after MapRoulette motorway downgrading task
Frederik Ramm wrote: > * you have developed a certain way to map certain objects, that might > be a little out of touch with what is considered the "right" approach > elsewhere in the project, but you don't notice or care Adding to which... I think half the problem is that the wiki documentation on US highway classification is confusing, contradictory and inconsistent. In the changeset discussion, UAN51 keeps referring to wiki pages that back up his way of doing things. It's understandable that he feels aggrieved that he's doing things by the book, and then someone comes along and tells him "you're doing it wrong" (though it would have been nice if it were expressed a little less confrontationally!). I've encountered similar situations a couple of times in the past, once going so far as to nuke an entire wiki page because it was actively misleading people (https://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System, as per https://www.openstreetmap.org/changeset/47671066). It would be great if a couple of people could take on the task of rationalising the docs and making it consistent. It's not my place to do so as a visitor from across the pond, but there are some smart and talented people on this list who I'm sure could make a good job of it, and I'd be happy to help if needed. Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways
Great to see so much attention being paid to rural TIGER fixup. The majority of my editing these days is that, and it's a massive but rewarding job. I put together a view a while back which superimposes unreviewed rural residentials onto the Strava heatmap. The idea is that you look for unobscured roads, then go in and fix them. It's at http://osm.cycle.travel/unreviewed.html . The "unreviewed" data comes from the cycle.travel rendering database, so there are a few optimisations (for example, it knows that all State Routes in NC are paved) and the update frequency is not fast (every month or two). But it's a good way of finding roads that are regularly used (by cyclists, at least) and are currently unreviewed. The one thing I would stress above all is that a surface= key (or equivalent) is crucial to denote unpaved roads - especially for cyclists and non-4x4 motorists. In the developed world in OSM, highway=unclassified and highway=residential are assumed to be paved roads in the absence of other information. So in (say) NY State, if you saw a highway=unclassified or highway=residential without an explicit surface tag, you'd assume it was almost certainly paved. Now in Kansas most roads are unpaved, but we can't expect people to do state-specific parsing - that way lies madness. Indeed, very few consumers do even country-specific parsing. So absolutely do change rural residentials to highway=unclassified, but add a surface= tag while you're there. A simple surface=unpaved is better than nothing, though obviously if you can be more precise with =gravel, =compacted, =dirt or whatever, that's great. I'd ask people setting up MapRoulette challenges and the like to incorporate this into their instructions - thank you! Having good paved/unpaved information will be a massive boost for OSM in comparison to other map providers. We're already partway there. As an example, try asking Google Maps for bike directions from SF to NYC. It sends you down some really, really unsuitable tracks and I'm not entirely convinced you'd survive the journey. By contrast, cycle.travel (using OSM data) gets it pretty much right: occasionally it takes a gravel road unnecessarily but it's pretty much always rideable. It would be great if we could become the best map of the rural US just as we are for much of the rest of the world. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Old Bing/ESRI satellite imagery?
The previous ESRI imagery has just been restored to the imagery list (by ESRI, so 100% legit) under the name “Clarity”. Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Integrating our open source data into OSM
Sean Lindsey wrote: > I do want to produce something that is useful for > open source and OSM/its community Let me join in the thanks for making this available. Even though it might not be suitable for direct import into OSM (for legal and/or community reasons), I wonder whether it might be suitable for seeding better POI mapping in the US. Minh Nguyen wrote the other year about POI deserts: https://www.openstreetmap.org/user/Minh%20Nguyen/diary/35646 If we know from your data that (to take an absolutely random example) Potlatch, ID[1] has a bank, a convenience store, a cafe and a pharmacy, but that none of these are mapped in OSM, this should be a prompt for mappers to go out, find and map them, whether from direct survey or from Mapillary/OpenStreetCam. The authors of those apps could even use this information to 'gamify' collection of new POIs. It would need a bit of careful thought about the legalities: my outline understanding is that it should be ok as long as there is no direct copying and that the data comparison is sufficiently abstracted (e.g. number of POIs compared within a 1km square) to ensure that genuine survey/cam-mapping has to take place. But LWG could no doubt advise further. If done right, I'd hope this could be the spur to greatly improving OSM POI coverage in the US. cheers Richard [1] yes yes, well spotted. http://www.cityofpotlatch.org/ -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trunk
Bradley White wrote: > The UK/Canada system and the central Europe system both adopt > the tag in a way that makes sense for the road network they > have. We are trying to shoehorn the central European tagging > system into our country when, to me, it makes more sense to > use the UK/Canada system. Just for information, if you wanted to adopt the UK system in the US, you could do that absolutely trivially by defining highway=trunk as those (non-motorway) roads within your National Highway System. That's pretty much analogous to how it's used here in the UK. https://en.wikipedia.org/wiki/National_Highway_System_(United_States) Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Bicycle infrastructure
Martijn van Exel wrote: > Do you see any improvements I should make to this query / am I missing > important features? Shoulder information is good, especially on rural roads. A simple shoulder=yes/no suffices. https://wiki.openstreetmap.org/wiki/Key:shoulder Surface information is good on rural roads too but I might have banged that drum one or 2,000 times before. Looking forward to seeing the result - I'll hold off the next cycle.travel North America update until you're done! cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger Zip Data Removal Project (Update)
Marc Gemis wrote: I wonder whether it is interesting to know the difference between concrete, asphalt and pervious concrete. All three have different characteristics whether it be comfort for the cyclist or being dangerous under icy conditions or durability under heavy loaded trucks. What do you think ? Is it worth recording those differences for paved roads ? Absolutely - it's certainly worth recording if you have the time and information. Similarly 'unpaved' is worth breaking down into dirt, gravel, fine_gravel etc. But OSM is iterative - data gets better over time. So if you're trying to make a lot of changes fast, paved/unpaved is much better than nothing, and someone can come along and make it more detailed later. I generally tend to concentrate on the paved/unpaved split but I'm always delighted to see when people have done more detailed tagging. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger Zip Data Removal Project (Update)
Kevin Kenny wrote: > Fair enough. I will confess that I'm a little lackadaisical about > tagging the surface on hard-surfaced roads. It appears that > some sort of hard surface is more or less assumed by default. > I do tag 'gravel', 'compacted', 'shale', 'sand', 'ground' > assiduously, and usually add some sort of assessment of > 'smoothness' on those. In that case you are absolutely on the side of the angels. Yes, if you clear the tiger:reviewed tag after reviewing that a residential (or unclassified, or tertiary, or greater) road genuinely does have a paved surface, that's AOK in my book - that's the assumed default for those highway values in developed countries. I generally wouldn't add surface=paved in such cases either. cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/Tiger-Zip-Data-Removal-Project-Update-tp5898958p5899343.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger Zip Data Removal Project (Update)
Bryan Housel wrote: > We haven’t discussed automatic removal of any other tiger tags. > (I don’t have a strong opinion for either keeping or removing them.) I have a really strong opinion _against_ removing tiger:reviewed tags where the road type and surface have not been manually reviewed! cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/Tiger-Zip-Data-Removal-Project-Update-tp5898958p5899332.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NJ mass road demotions?
Kevin Kenny wrote: > Is there *anyone* that actually can speak to what *is* common > practice in the US? When I've asked, I've always drawn a lot of > replies and come away more confused than before. I've been doing vast amounts of rural TIGER fixup over the past couple of years and this is what broadly seems to be what I've seen, bearing in mind standard practice in other developed countries and the idea that the highway= tag combines the importance in the highway network with some assurance of construction quality: * highway=motorway: interstate or other long-distance restricted-access road * highway=trunk: fast, busy State Highway or US Highway, often NHS/STRAHNET * highway=primary: major State Highway or US Highway * highway=secondary: other State Highway or major County Road * highway=tertiary: other through route, often a County Road, usually paved with centreline * highway=unclassified: rural minor route, sometimes a County Road, paved unless tagged otherwise * highway=residential: minor public road intended for residential access rather than through route, paved unless tagged otherwise (N.B. currently not safe to assume paved in rural areas where tiger:reviewed=no) * highway=track: ungraded or rough, but usable by some four-wheeled vehicles There are many, many variations, especially because the US doesn't have a single nationwide system like most European countries, but if I had to sum it up in a few words I'd choose the above. cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/NJ-mass-road-demotions-tp5894719p5897836.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NJ mass road demotions?
Albert Pundt wrote: > This seems like a way overboard change. I've just received a changeset message back from someone else who had made a few unusual reclassifications, in this case highway=secondary for dirt roads in Nebraska. The user explained that they had been working from this wiki page: https://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System which is a pretty misleading page for a newcomer to stumble upon, and doesn't accord with common practice. The page was created by one user in 2009 and has barely been touched since.[1] There are other very verbose pages: https://wiki.openstreetmap.org/wiki/United_States_roads_tagging https://wiki.openstreetmap.org/wiki/Talk:Highway_tag_usage and, of course, US information on international pages like https://wiki.openstreetmap.org/wiki/Highway:International_equivalence . It would be really helpful if there were one single place where US common practice was explained, succinctly (not like the verbal diarrhoea[2] on the US Roads Tagging page) and unambiguously, and in a way that accords with international usage in OSM. As an auslander it's not my job to do it, but perhaps someone sensible on this list might like to? Richard [1] I've now added big messy warnings at the top of the page [2] it does actually include the phrase "according to the criteria heretofore described", which is marvellous -- View this message in context: http://gis.19327.n8.nabble.com/NJ-mass-road-demotions-tp5894719p5897823.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NJ mass road demotions?
Bryan Housel wrote: > What’s an acceptable amount of time to wait for a response before I > just start reverting? I commented on another of granpueblo's changesets on 21st May and have also not had a response yet. Given that, you probably only need to wait just a couple of days before embarking on a revert. (More generally, we need to think about how we communicate "be bold in what you add, careful in what you change" to new mappers. We see this fairly often in the UK too - over-assertive changes from someone who, through no fault of their own, doesn't understand OSM conventions; and on occasion the response ends up putting the contributor off continuing with OSM.) Richard -- View this message in context: http://gis.19327.n8.nabble.com/NJ-mass-road-demotions-tp5894719p5897753.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Unreviewed TIGER in Jacksonville (was Re: Talk-us Digest, Vol 114, Issue 22)
maning sambale wrote: > While our team is working on Jacksonville, we found unreviewed > TIGER (v1, tiger:reviewed:=no) in some areas. I don't want to dismay you too much, but 90%+ of the US is like that... (...though don't take v1 as an important signifier: it's possible for a way to be at v3 or v5 or whatever, but actually all the versions are automated edits deleting unnecessary TIGER tags, rather than genuine human review.) There are massive opportunities to improve the unreviewed TIGER data across the US and it would be good to have that discussion here. But the sine qua non: please do not delete tiger:reviewed from any highway type which is usually paved in developed countries (e.g. residential) unless you're genuinely reviewing the surface type. Kansas is a disaster area for routing because of the number of dirt tracks or worse which are tagged as residential with no tiger:reviewed tag. cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/Unreviewed-TIGER-in-Jacksonville-was-Re-Talk-us-Digest-Vol-114-Issue-22-tp5897513p5897528.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] People For Bikes Connectivity Tool
Spencer Gardner wrote: > The tool uses OSM for routing and uses information such as speed > limits, number of vehicle lanes, the presence and type of bicycle > facilities, and the types of treatments at intersections/crossings > for determining whether a particular way is acceptable for bicycling > or not. In places where data is limited, assumptions are made > based largely on the road classification. This looks great. It would be good to share your recipe (as per "fully transparent set of calculations") so that others can suggest improvements, and so that bike routing tools can make maximum use of the data you're encouraging people to collect for OSM. Richard https://cycle.travel/map -- View this message in context: http://gis.19327.n8.nabble.com/People-For-Bikes-Connectivity-Tool-tp5894902p5894916.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Key:man_made... Outdated language?
Joshua Houston wrote: > It occurred to me that "man_made" is an outdated term that should be > phased out from OpenStreetMap language. FWIW, the lingua franca of OSM tagging is British English: so, colour rather than color, and so on. British English does of course have different cultural assumptions to American English. As an example in the opposite direction, I remain genuinely astonished that there is a US movement called "GeoLadies". Here in Britain, if you described any woman under 80 as a "lady", you would probably be expecting a slap; it's generally a patronising and slightly pejorative word with connotations of passivity and indolence, and outside of those parts of London influenced by the US, I don't see that it's been reclaimed. That isn't to say that GeoLadies is objectively wrong: it isn't wrong in the slightest. Just that, inevitably, some cultural references fall differently in different parts of the world. man_made is possibly not too different. I can see how it might sound jarring to US ears but it's not something at which anyone would bat an eyelid in Britain. (And of course, going to the country where OSM has historically been strongest, "man" is a neutral pronoun in German.) Nothing is going to be entirely consistent across all the cultures in which OSM is used. Of course, there is a great irony in that this thread has been populated by people called Joshua, Joel, Ian, Brian, Harald, Mike, Frederik, Blake, Clifford, Kevin, and Richard, so maybe we should shut the heck up and let some women have their say. cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/Key-man-made-Outdated-language-tp5892860p5892877.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blue Ridge Parkway
Greg Troxel wrote: > Around me (amusingly as we discuss British influence on tagging) > is "Minuteman National Historic Park". This is not a "National Park", > but it has the same kind rangers in the same uniforms, the same > kinds of rules, and is managed to preserve the historic landscape FWIW, even the Broads in the UK are tagged as boundary=national_park, even though strictly speaking they're not a National Park (there are long and boring reasons for this but I'll spare you). As ever, if it quacks like a duck, tag it as a duck. Richard -- View this message in context: http://gis.19327.n8.nabble.com/Blue-Ridge-Parkway-tp5890228p5890296.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] highway=trunk for NHS routes?
voschix wrote: > The answer is definitely NO. > You can find detailed PDF maps of all NHS Routes, state-by-state at a > web page of the Federal Highway Administration [1]. On these maps > you will find plenty of NHS roads that are definitively not trunk roads. > Just two examples in Arizona: [2] [3] That's not too outlandish. The UK usage of highway=trunk, which historically is the original usage (as Map Features was devised in the UK by Andy Robinson and first applied in the UK), includes plenty of roads like that or worse. There is no implication in the UK that highway=trunk means a dual carriageway (divided highway), limited access, grade-separated junctions or anything like that - it's just the network of the most important roads between cities and towns, which are A roads signposted with green signs. We're a small, dense and often hilly country, so these roads can sometimes be narrow and winding. Since then other countries have adopted their own local definitions, which often include minimum infrastructure requirements. That's absolutely fine, and that's their right, but it's also fine for the US to adopt a definition which might be closer to (say) the original UK one than to the German one. Albert's suggestion of equating it to the National Highway System would be very close to the UK definition. (FWIW, the current distinction between highway=trunk and highway=primary in the US seems so arbitrary that I actually render them both the same for cycle.travel.) cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/highway-trunk-for-NHS-routes-tp5888347p5888378.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] .... finding areas that are underserved
Minh Nguyen wrote: > The entire state of West Virginia -- no exaggeration. The original data > imported from TIGER is badly misaligned throughout this state > and rarely resembles the road network at all. *shudders* Yes. Genuinely the worst geometry I've encountered anywhere in the US, and that's saying something. Richard -- View this message in context: http://gis.19327.n8.nabble.com/finding-areas-that-are-underserved-tp5885803p5886221.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] .... finding areas that are underserved
Markus Fischer wrote: > I am new to this and the area where I live is very well > mapped (probably due to high density of tech workers). > Where do I go to start mapping areas that are less well > mapped (me aimlessly poking at this does not sound > like a good approach)? Possibly the biggest issue with OSM data in the US is rural roads from the original TIGER import which haven't been touched. These were imported as highway=residential, which in developed countries in OSM generally means a paved road principally used to access residential properties. Sometimes they are indeed rural residential roads, but often they're rough tracks, ditches or worse. Fixing these to their correct highway types is an easy (but massive!) job. I tend to broadly go by this rule of thumb, though obviously being aware of local circumstances: * well-maintained paved road with centreline -> highway=tertiary * other paved road -> highway=unclassified * unpaved graded country road -> highway=unclassified, surface=unpaved (or =gravel, =dirt...) * unpaved road to houses -> highway=residential, surface=unpaved (or =gravel, dirt...) or for driveways: -> highway=service, surface=unpaved (or =gravel, dirt...) * track, not suitable for general traffic -> highway=track and I have function key shortcuts set up in Potlatch 2 for most of these. Where a road genuinely is a paved residential road then you can just remove the 'tiger:reviewed=no' tag (or change the 'no' to 'aerial'). Please don't remove this tag if you haven't reviewed the road type, because otherwise routers will think "oh, that must be a decent residential road" and send poor unsuspecting bicyclists to die on rough tracks in the desert. :( http://cycle.travel/map (my site!) shows rural roads with highway=residential, tiger:reviewed=no as faint dashed grey lines when you zoom in - for example, http://cycle.travel/map?lat=33.9483=-102.0613=13 - and it has a little icon for editing this area in OSM right at the bottom right corner. It's not updated very often so don't use it as a record of what you've done, but it's useful for identifying areas that need fixing. cheers Richard -- View this message in context: http://gis.19327.n8.nabble.com/finding-areas-that-are-underserved-tp5885803p5885984.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Common names of highways do not match road signs.
Greg Troxel wrote: > When converting to garmin format with mkgmap, and I think with osmand, > I will tend to hear both the name and the ref. That's a big lengthy, but > there's no real pattern on which to leave out. For cycle.travel's directions in the US, I've started post-processing the name and ref tag to remove duplication. So if name=State Route 315 and ref=OH 315, for example, it will simply say the road to follow is "OH 315" rather than "OH 315 State Route 315". But this requires some Lua string-matching magick which I suspect is outwith the capabilities of mkgmap. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Common-names-of-highways-do-not-match-road-signs-tp5877606p5877795.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Best practices for dealing with old TIGER tags?
Madeline Steele wrote: > What do you all think about this? The sine qua non for me is that the absence of a tiger:reviewed= tag (or one set to =yes) means that you can trust the value of the highway= tag. This is especially true of rural areas where unreviewed highway=residential covers a multitude of sins. There is a special corner of hell/Steve's basement for people who remove tiger:reviewed=no on rural unpaved roads without changing the highway tag or adding a surface tag. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Best-practices-for-dealing-with-old-TIGER-tags-tp5874640p5874647.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Colorado mappers: Check your notes carefully
SteveA wrote: > [Great Divide Mountain Bike Route] > where MountainAddict keeps setting this to network=ncn > when clearly it is network=icn (as it crosses the Canadian > border in Alberta). A partial compromise/consensus > solution has emerged: keep a duplicate relation synced as > route=mtb. OK, that makes sense. Yes. It shouldn't really be route=bicycle at all. route=bicycle generally implies a designated (and, in other parts of the world, signposted) bicycle route which has been assessed for safety and other suitability for general-purpose bicycles. Bike routers can and do give such routes preferential weighting. The GDMBR isn't such a route. It should be route=mtb, not route=bicycle, because it's meant for MTBs - not just "bicycles". I understand that the original GDMBR mapper was unhappy with route=mtb as it didn't render prominently on OpenCycleMap, but that's now been fixed so shouldn't be an issue. That said, life is too short to get into edit wars on such things, so I was happy with just having a manual override in cycle.travel's US routing profile: if route_ref=='GDM' then -- ignore this route else -- ...until someone decided to change the ref from GDM to GDMBR. :| cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Colorado-mappers-Check-your-notes-carefully-tp5872836p5872870.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Slack
Martijn van Exel wrote: > The web site has always been about the map primarily, > not the people. I am curious if there are any ideas out > there to change that. Groups! cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Slack-tp5870718p5870933.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations
Richard Welty wrote: > the key thing, i think, is that mappers have little motivation to > work on route relations if they don't actually get used by > anything. Don't forget that the issue is not an endemic issue with route relations, it's just an osm2pgsql issue. osm2pgsql is the most popular tool for loading data into a database for raster rendering. But it's not the only one; that's not the only use case for OSM data; and who knows whether osm2pgsql will remain pivotal as vector rendering supersedes raster rendering. I use Interstate route relations as a small part of cycle.travel's routing algorithm, for example. "Anything" is a big word! Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-Proposal-Sunset-ref-on-ways-in-favor-of-relations-tp5859312p5859503.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Increasing the number of US Mappers
Paul Norman wrote: > The problem is that if you make a discussion group too small, it > doesn't have enough activity to sustain interest in it. > > Larger regions might work, but even a statewide group abandons > the might meet for a geobeer idea where it takes 6 hours to drive > across the state. > > Unfortunately, I don't have any great ideas. Groups on osm.org. Mailing lists only appeal to a certain subset of people. They look geeky, they require yet another login/subscription, and we all get too much email anyway. They're good for engaging the kind of people who like mailing lists, but these days that doesn't include a lot of tech-savvy people. The idea behind having groups on osm.org is to encourage self-organising communities, whether by region or topic. You don't have the hassle of finding out who the OSM lists administrator is, emailing them, convincing other people to join, etc. etc. You just go to osm.org and start a group. If it doesn't work because the area is too small/too big, no problem, you try another one. Users can join groups, and then when they post diary entries, can optionally tag them as belonging to the Oxfordshire group or the cycle-mapping group or whatever - and there you go, that's a discussion facility. Groups have bounding boxes which enables the site to suggest that people might want to join the group in the area they edit (maybe even on sign-up). So it's not a big change, but it makes much better use of the existing social functionality on osm.org (diary, home location, etc.) than we're already doing. We got some way with implementing it but the effort stalled; I got stuck trying to figure out how pagination works on osm.org! But I would love to see coding resume on it and will happily take part if it's not just me working solo. http://groups.apis.dev.openstreetmap.org/diary http://groups.apis.dev.openstreetmap.org/groups/4 https://github.com/openstreetmap/openstreetmap-website/pull/297 cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Increasing-the-number-of-US-Mappers-tp5857059p5857085.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Increasing the number of US Mappers
On 15/10/2015 14:28, Bryan Housel wrote: Agree with everything you said about *why* groups are important, except that: now that it's 2015, Facebook groups is really a better place for this. Yeah... but no. Every time this comes up, someone suggests "use my favoured platform". Which might be Facebook, or it might be Google Groups, or Meetup, or whatever. Which is tempting, except these platforms have incredibly uneven penetration both demographically and geographically. Chatting to three friends in the pub last night (all older than me, none geeky, one even of American birth) I was interested to find I was the only one on Facebook, and even then I'm a pretty reluctant user.[1] The other three had made a conscious decision to stay away. You can _get_ people to OSM via Facebook; it's one of many good channels for that. And you can use it to organise within a particular demographic, particularly young and urban. But it's not an answer to "how do we make mapping fun and 'sticky'?", whereas groups on OSM can be. You can integrate OSM groups into the discovery process - sign up, have groups suggested to you, get invites from people who've seen your mapping - which you can't easily do with a third-party solution, especially given the Facebook real name/OSM username mismatch. cheers Richard [1] Anecdata alert: if you extrapolate that 25% across the 3,000 population of Charlbury, it looks pretty sickly compared to the 2,400 registered users of the Charlbury website. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Extra wide shoulders / travel lanes in NJ
Elliott Plack wrote: > I am now leaning towards the shoulder tag, and perhaps > recommending that the routing tools consider that. I'd be genuinely delighted to add shoulder support to cycle.travel when there's more than a trace number of shoulder tags present in the OSM database - missing shoulder information is the second biggest bike routing issue in the US IMO (after bogus TIGER highway=residential, of course). But as Paul says, please don't misuse cycleway tags for this. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Extra-wide-shoulders-travel-lanes-in-NJ-tp5856823p5856885.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)
Greg Troxel wrote: > It's perfectly reasonable to have an unpaved highway=secondary in > rural areas, if that's one of the major roads around. ...with the proviso that it _must_ be tagged as surface=unpaved (or a more detailed tag, such as surface=gravel or surface=dirt). Standard tagging in developed countries is that such roads are assumed paved unless otherwise specified. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Another-road-classification-disagreement-this-time-with-HFCS-in-Kansas-tp5854071p5855178.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)
Richard Welty wrote: > i could see having an HFCS tag which carries that value for > informational purposes, but it shouldn't control our own classification. In the UK we use the designation= tag to record official classifications which might not be reflected in the highway type - I'd commend it. Toby Murray wrote: > This user has also upgraded a lot of unpaved county roads in > eastern Kansas to secondary because of HFCS which also strikes > me as wrong. You can clearly see where he has done this at > zoom level 9 [6]. Ye gods. That's horrid, and breaks every single car and bicycle router in existence. Are those changesets cleanly revertable, or do we need a manual fixup? Richard -- View this message in context: http://gis.19327.n5.nabble.com/Another-road-classification-disagreement-this-time-with-HFCS-in-Kansas-tp5854071p5854085.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)
Richie Kennedy wrote:
> As to Mr. Fairhurst’s comment regarding routing, I’ll remind you
> it is frowned upon to tag for a routing engine.
Given that Mr Fairhurst has been involved in OSM since month 4 in 2004, he
is quite aware of what is frowned upon and what isn't, but he thanks you for
your kind, if slightly patronising, concern.
Following international common practices is not tagging for the router, or
the renderer, or the autonomous self-guided robot or whatever. It is an
essential part of a mass collaborative project, and is the only way from
preventing OSM descending into an anarchy of local exceptions.
It is universal that, in developed countries such as the US, Canada or any
part of Western Europe, a highway=secondary is assumed paved _unless_ a
surface (or similar) tag is used.
Piling up local exceptions justified by obscure wiki pages (and, to be
honest, you can justify classifying US roads any old way given the morass of
contradictory wiki pages) makes for data that no-one can sanely use. I
probably do more post-processing of highway tags than anyone else and even I
draw the line at "if (highway=='secondary' && last_editor=='route56') {
surface=UNKNOWN; } else { surface=PAVED; }". This is a collaborative
project; it only works if we pull in the same direction.
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Another-road-classification-disagreement-this-time-with-HFCS-in-Kansas-tp5854071p5854090.html
Sent from the USA mailing list archive at Nabble.com.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Does anybody know if these PA maps are legal to use to get info from for OSM?
James Mast wrote: I mean, would he have to at least verify that the license for those maps is compatible with OSM first Yes, and it isn't. The licence has lots of clauses that aren't compatible with ODbL, the Contributor Terms or indeed any open licence: ftp://ftp.dot.state.pa.us/public/pdf/BPR_pdf_files/Documents/Cartography/COPY_RELEASE_FORM%20(01_07).pdf That said, it might be worth someone approaching the Pennsylvania DOT to ask for permission. But as it stands, these terms aren't at all compatible. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Does-anybody-know-if-these-PA-maps-are-legal-to-use-to-get-info-from-for-OSM-tp5851488p5851489.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Harald Kliems wrote: Until then you could consider a user setting to avoid/not avoid unpaved roads. Unfortunately contraction hierarchies - the routing algorithm used by OSRM - don't really allow user settings. For each distinct routing profile, you need to regenerate the routing graph, which takes (many) hours and requires (many) GB of RAM both to route and to host. cycle.travel penalises surface types variably: surface=mud gets a big penalty, surface=gravel not so much. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/cycle-travel-US-bike-routing-and-unreviewed-rural-TIGER-tp5848084p5848600.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Just as a postscript to this discussion I thought I'd cite an example area. If you look here, in Georgia: http://cycle.travel/map?lat=31.9023lon=-84.0398zoom=14 you'll see that most of the roads are unreviewed TIGER residentials. Of those, these are adjacent to each other: http://www.openstreetmap.org/way/9359782 - good tarmac, should be highway=tertiary http://www.openstreetmap.org/way/9359913 - unpaved road; highway=unclassified, surface=unpaved http://www.openstreetmap.org/way/9359784 - probably tertiary, but lousy geometry at the S http://www.openstreetmap.org/way/9359783 - whoops, where did the connectivity go? All of this is trivially fixable but right now there's no way of using them for routing or sensible cartography. Do dive in - the cycle.travel rendering makes it obvious which bits need fixing, and you learn to identify the roads which are likely to be paved through roads and therefore targets to fix. It's quite good fun. :) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/cycle-travel-US-bike-routing-and-unreviewed-rural-TIGER-tp5848084p5848589.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
SteveA wrote: Richard (Fairhurst), if cycle.travel/map's router logic is not paying attention to surface= tags, perhaps it should, as doing so truly can improve selected routes It very much does - it'll look at surface=, and failing that tracktype= or smoothness=, as one of the principal criteria for how cyclable is this?. I've suffered on too many bumpy dirt paths in my time to let that one past! cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/cycle-travel-US-bike-routing-and-unreviewed-rural-TIGER-tp5848084p5848239.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Harald Kliems wrote: Very nice, Richard! One quick comment: I might not be the only who doesn't always change the tiger:reviewed tag when fixing TIGER-imported roads. I don't know if that's technically feasible, but maybe it would be better to check if a way has been modified since import, independent of the tiger:reviewed tag. Absolutely. I did consider this and it's very feasible - osm2pgsql can tell you the user who last modified a way, and if it's DaveHansenTiger or woodpeck-fixbot, you can presume it's unmodified. Unfortunately, there are way too many false positives. Partly this is consequential damage (in particular, ways which have been split) but also bulk edits - for example, in several of states, people have assigned (say) maxspeed=35mph to all ways matching certain criteria, including dirt tracks tagged as highway=residential. This means the last editor is no guarantee that a residential is actually a usable paved road. After a few experiments (and I've been working on this all year, pretty much) I concluded that the tiger:reviewed tag is the only way of doing it. I'd restate that I'm only using this on rural residentials - anything unclassified or higher, or in an urban area, is assumed ok. Personally I have F6 assigned as a shortcut key in P2 for highway=unclassified for ease of quick retagging. :) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/cycle-travel-US-bike-routing-and-unreviewed-rural-TIGER-tp5848084p5848141.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Hi all, At State of the Map US last weekend I was really pleased to unveil bicycle routing for the US (and Canada) at my site, cycle.travel. The planner, at http://cycle.travel/map , will plan a bike route for you between any two points - whether in the same city or on opposite sides of the continent. It's all based on OSM data but also takes account of elevation and other factors. I dogfooded it with a three-day ride around New York state after SOTM-US, and it found me some lovely quiet roads in and around the Catskills. I hope it'll be equally useful for the other two-wheelers amongst us. There's still a lot I want to add (as detailed at http://cycle.travel/news/new_cycle_travel_directions_for_the_us_and_canada) but I hope you enjoy it. Plug aside, there's a couple of things might be relevant to US mappers. First of all, I'm aiming high with this - the aim isn't just to make the best OSM-powered bike router of the US, but the best bike router full stop for commuters, leisure cyclists and tourers. (I leave the athletes to Strava!) Here in Britain, experience over the years has been that good bike routing and good bike cartography - historically via CycleStreets and OpenCycleMap - are a really effective way of driving contributions to OSM. So if you know cyclists who aren't yet contributing to OSM, maybe throw this at them - and if it doesn't find the route they'd recommend, maybe there's some unmapped infrastructure they could be persuaded to add! Second, the routing and cartography both heavily distrust unreviewed TIGER. In other words, it won't route over a rural road tagged as highway=residential tiger:reviewed=no Any road with tiger:reviewed removed or altered, any road in urban areas, and any road with highway=unclassified or greater is assumed to be a usable paved road. (There are a few additional bits of logic but that's the general principle.) Unreviewed rural residentials are shown on the map (high zoom levels) as a faint grey dashed line, explained in the key as Unsurveyed road. I've been finding this a really useful way of locating unreviewed TIGER and fixing it... it's actually quite addictive. :) Looking for roads which cross rivers, or with long sweeping curves, is an easy way of identifying quick wins. My modus operandi is to retag 2+-lane roads with painted centrelines as tertiary, smaller paved roads as unclassified, and just to take the tiger:reviewed tag off paved residential roads. Anything unpaved gets a surface tag and/or highway=track. I can't promise minutely updates I'm afraid - the routing/map update process takes two full days to run so it'll be more monthly than minutely. But I hope you find it as useful as I do. You'll see there's a tiny little pen icon at the bottom right of http://cycle.travel/map which takes you to edit the current location in OSM. Finally, many thanks to everyone who's tested it so far, particularly Steve All - your feedback was and continues to be enormously useful. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap
Frederik Ramm wrote: The problem of OSM editors being confused by a strange line that cuts through houses in the editor perhaps. Which is perhaps 0.1% of the (largely rural) abandoned railroads mapped in OSM, so largely immaterial to the discussion. And if you're confused by that 0.1%, heaven knows what you'll do when faced with the superfluity of admin boundaries in many parts of the world. (And let's not start on proposed highways.) I'm fully with Russ and Greg on this one. For the few vocal deletionists who seem to have ants in their pants about this, may I suggest that you just learn to read 'railway=abandoned' as 'manmade=former_railway_grade', which is entirely verifiable and consistent with OSM's approach of meaningful broad-brush duck tagging. Thanks. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Moving-historic-railroad-ways-from-OSM-to-OpenHistoricalMap-tp5839116p5839518.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
Greg Morgan wrote: 2. To quote Richard Fairhurst, Seriously, OSM in the [England] s still way beyond broken. You can open it at any random location and the map is just __fictional__. Here are two random examples bing;OS StreetView [2] shape is approximate. Needs proper survey as mostly built after current BING imagery date [3] I have no idea, at all, what point you are trying to make, but I would appreciate it if you didn't make it by deliberately misquoting me. Thank you. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Retagging-hamlets-in-the-US-tp5837186p5838190.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] GNIS POI populations
Minh Nguyen wrote: I think we should consider a mechanical edit to update these tags While you're thinking about GNIS mechanical edits, could I suggest one for GNIS-sourced POIs with (historical) in the name? There are several gazillion amenity=post_office, name=Fred Creek Post Office (historical) in the database. Clearly these aren't actually post offices any more. Ideally I guess they should be disused:amenity=post_office, or historic:amenity, or something. https://www.google.co.uk/search?q=site%3Aopenstreetmap.org+gnis+historicalgws_rd=ssl I'd do it myself but this is about the one area where you _do_ need JOSM rather than P2. ;) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/GNIS-POI-populations-tp5829895p5829925.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Bike route relation issues
Hi all, I've encountered two problematic bike route relations in the US and would appreciate thoughts as to the best way to deal with them. One is the Great Divide Mountain Bike Route: http://www.openstreetmap.org/relation/3161159 The other is I-5 in Oregon: http://www.openstreetmap.org/relation/69485 Both are tagged with type=route, route=bicycle, network=rcn. In both cases they're not of the same character that one would usually expect from a long-distance RCN route. One is mostly unsurfaced and therefore requires a certain type of bike; the other is entirely Interstate and therefore requires a confident rider. I changed the GDMBR to route=mtb (which is how it'd be tagged elsewhere in the world), but the original editor has since changed it back with a plaintive changeset comment in http://www.openstreetmap.org/changeset/27862412 . The I-5 relation seems wrong to me (it's not really a bike route per se, it's an all-purpose route on which bikes are permitted) but I'm not too worried as it's easy to find its character by parsing the constituent ways, which are all (of course) highway=motorway. But the GDMBR is very problematic in that many of its constituent ways are highway=residential, without a surface tag. Until these ways are fixed, the relation is very misleading and likely to break bike routing (which generally gives an uplift to bike route relations) for all apart from MTB-ers. Ideally I believe it should be route=mtb, but the original creator seems hostile, perhaps for prominence on OpenCycleMap issues. (I've messaged him but no reply as yet.) There may, of course, perhaps be another commonly used tagging that I'm not aware of. What does the community think? cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fix a Forest - experimental tiles from US Forest Service data
Hi all,
I've created a set of tiles from US Forest Service road data for the 155
US National Forests.
This is to help with TIGER fixup in these rural areas, where tracks,
trails and entirely non-existent paths are often tagged with a bare
highway=residential. The US Forest Service data is greatly superior to
the original TIGER data and has metadata on surface type/quality, but is
unsuitable for automatic import into OSM because it would overwrite
mappers' existing work in these areas.
You can access the tiles at:
Potlatch 2/JOSM - http://osm.cycle.travel/forest/{zoom}/{x}/{y}.png
iD - http://osm.cycle.travel/forest/{z}/{x}/{y}.png
and they're included in the editor-imagery-index list used by P2 and iD.
The tiles are available up to z19. Use of Potlatch 2's new floating
imagery window mode is recommended, so that you can work from both Bing
imagery and these tiles at the same time. :)
You can also explore from the comfort of your browser:
http://osm.cycle.travel/index.html
where there's an Edit this area in OpenStreetMap link at the bottom right.
The key is:
Surface:
yellow outline = paved
grey outline = gravel
Road type:
white with black casing = paved road
dashed grey = gravel road suitable for cars
dashed brown = dirt road
dotted grey = not maintained for cars
Maintenance level:
grey dots = 4x4 only
green dots = usable by cars
black dots = moderately comfortable for cars
black frequent dots = very comfortable for cars
Points of interest:
car = roadside park
flag = Forest Service station
ski = winter recreation area
hiker = trailhead
campsite = campsite
picnic site = picnic site
(There's some degree of overlap, but this is present in the original
USFS data.)
When remapping, I would suggest the following tags as a minimum:
highway=unclassified - paved road
highway=unclassified, surface=unpaved/gravel/dirt - unpaved road
suitable for cars
highway=service - road to isolated dwelling or other building
highway=track - unpaved track or road suitable for 4x4s
highway=path - narrow linear clearing, too narrow for motor vehicles
[delete entirely] - raw TIGER data with no signs of track or path in
either imagery or Forest Service tiles
US Forest Service data is public domain so there's no need for further
attribution when using this data, though a source= tag is always good
practice.
Hope these are helpful, and let me know of any further suggestions.
cheers
Richard
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fix a Forest - experimental tiles from US Forest Service data
On 11/11/2014 20:57, Clifford Snow wrote: Suggestion - set the tile background to transparent so we can see underlying image in JOSM. I can certainly have a look at doing that. Do you/anyone know whether transparent tiles would still be usable in iD? cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Statistics of board candidate edits
A friendly thought from across the pond; just something to provoke thoughts, feel free to disregard. OSM in the US is without doubt the #1 country at organising conferences. I was privileged enough to go to Portland and SF and they were both superb events. (This year's SOTM-EU in Karlsruhe was, of course, the other one making up the top 3, and I couldn't choose between them.) The US is probably also the #1 country at encouraging corporate use of OSM - I don't need to bring up the examples, you know them better than me. And there are lots of other accolades in your national palmarès. The one area where I could unequivocally say the US isn't yet #1 is in the quality of the map. #1 is clearly Germany (curse those crazy Teutons); but Britain, France, and, quite seriously, Russia are not far behind. Your new board's responsibility is to make OSM grow, in every way, within the US. That means continuing to be #1 at conferences and #1 at corporate use, but it also means improving on the #5 ranking for map quality. You do of course have Martijn, who has forgotten more than most of us ever knew about OSM data in the States; Alex's great work in urban areas with Mapbox; and no doubt many more I'm not aware of. Paul's analysis is just one data point but I hope, for anyone who thinks understanding US data quality is an issue, it could at least be a relevant one. Elect a great board - I'm sure you will. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Statistics-of-board-candidate-edits-tp5819107p5819739.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)
Greg Morgan wrote: It feels like the discussion is about fixing a routing problem when in reality you would exclude people that want to make it to Cleator Arizona or other recreational destinations. The people at the Cleator Bar and Yacht Club[4] would question your judgement that this a fictional place or that is not a meaningful destination. No, you misunderstand. No-one is going to entirely delete roads/tracks that exist in reality. The prevalent issues with backwoods TIGER are: a) highway=residential on roads/tracks that go nowhere near a residence b) highway=residential where no road/track exists of any sort c) no indication of surface type (bearing in mind that the rest of the developed world predominantly uses highway=residential for a paved road) How you solve these issues is your decision as the US community. If you want to keep highway=residential for the tracks that exist and add a surface= or tracktype= tag, you do that. Personally I would suggest that you use either highway=track or highway=unclassified and add a surface tag, but it ain't my country. The good thing about this discussion is that ideas are emerging about how to solve the problem, both in tagging and in resources. Distinguishing between gravel roads, forest tracks, suburban streets and non-existent things - all of which might currently be mapped as highway=residential - isn't excluding people who want to make it to Cleator, Arizona. Quite the opposite: a more accurate, clearer map, whether for rendering or routing, for truck drivers or car drivers or cyclists, makes it easier for people to get to Cleator, Arizona, and a thousand other places. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-Dirt-Roads-formerly-Abandoned-railway-tp5815986p5816758.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)
Richard Welty wrote: agreed. i have spent quite a lot of time in Iowa farming territory where the road grid consists mostly of high quality, well maintained gravel roads that are in regular, heavy use by farm equipment. i generally give these highway=unclassified, surface=gravel. Great to see this issue getting some airtime. Obviously it's entirely your choice nationally as to what tags you use, as long as they don't diverge too wildly from the rest of the world. Having a distinction between highway=track and highway=unclassified;surface=gravel is certainly one possibility. It doesn't really matter as long as there's agreement and a will to fix it. I think the other half of the equation, however, is actually getting this fixed across the country. At present it appears to be just a small number of mappers doing it in their areas; the US is a big place, and at the current rate it's not going to be fixed any time soon. Drive-by tools like MapRoulette are generally a good solution for systemic data quality problems, but in this case I think the problem's too big for that. What would help here? A Tasking Manager instance with defined areas (say, 10km x 10km, or counties, or...)? Anything else? cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-Dirt-Roads-formerly-Abandoned-railway-tp5815986p5816149.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abandoned railway
Russ Nelson wrote: I fear that the deletionism infection has jumped from Wikipedia to OpenStreetMap. ...is exactly what I was going to say. Seriously, OSM in the US, outside a few cities, is still way beyond broken. You can open it at any random location and the map is just fictional. (I did, just now: http://www.osm.org/edit#map=13/36.1938/-103.6446 . Half of those roads don't exist at all, and the other half are barely roads, certainly not residential ones as tagged.) Why would you (contentiously) delete railway=abandoned for an actual abandoned railway trackbed when the map has thousands, millions, of fictional or entirely mistagged roads and tracks? I know it's a long-standing OSM joke, but at this rate we _are_ going to have to import some Germans to the US, because it looks like the only way the map will ever get fixed. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Abandoned-railway-tp5815752p5815879.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abandoned railway
Mike N. wrote: Landing on the high plains desert in the west does not make a good case that OSM in the US is broken. Desert imagery cues do not match those of conventional climates. I really wish I could agree with you, Mike, but my experience is that ~75% of the US landmass is like that. I just randomly alighted on somewhere in Texas. It's the same story. 'highway=residential's that don't exist or are, at best, very faint farm tracks at the edge of a field. The majority of the roads I click on just aren't there. Now looking at somewhere random in Missouri. It's better - the geometries are reasonably well lined up with the imagery. I'd say that around two-thirds of the roads I'm clicking on are actually roads, and perhaps just one-third are faint tracks or just non-existent. The US community (and, dare I mention it, the late NE2) has done really well cleaning up the major road data. If you're going from somewhere biggish to somewhere biggish in a car, the routing will generally be good. I can happily get OSRM to route from town to town and it works fine. But that's not a map, that's a sparse routing graph. If I pick a random highway=residential anywhere in the US, I have no confidence that it'll be drivable in an average car or cyclable on an average bike. I certainly couldn't expect it to be a road principally for residential access, in the way that the rest of the world uses highway=residential. And that's without going into nice-to-haves like rivers and woodland and so on. I don't think people realise quite how far behind OSM is in the US (the biggest cities aside) compared to Western Europe. I can look anywhere in the Highlands of Scotland, or barely-inhabited Mid-Wales, and OSM will be right. Sure, some of the rarer footpaths might be missing and the stream geometry might be a bit skewiff, but most information will be there, and what's there will be correct. Similarly, la France profonde has come on in leaps and bounds over the last couple of years. I don't need to tell you about Germany. :) Fixing the rural US is eminently achievable, and achievable right now. A Tasking Manager instance, for a clearly defined project, would be great. I think you'd get the armchair mappers of the world rallying to the task. If you wanted to widen participation, you could probably build a MapRoulette-on-steroids that provided a fast retagging UI within the browser, with no need to fire up an editor. Or whatever. But we can't get to OSM's 20th birthday and still have the same problem. It needs to be fixed sooner or later, and my sense is that, at the current rate of progress, it will be later - probably not within the next ten years. Let's decide to make it sooner instead. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Abandoned-railway-tp5815752p5815918.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Martijn van Exel wrote: I would love to see these routes in OSM, and I think it's a shame that there is such an ongoing fuss about it. May I gently offer some experience from n years of both mapping and developing National Cycle Network routes in the UK. (As well as being an OSMer I'm a regional group co-ordinator for Sustrans, the organisation that looks after and develops the NCN.) Generally in the UK we only map proposed NCN routes when a) we have some personal knowledge of them, and b) the route has a serious likelihood of being signposted in the next couple of years For example, I was happy to map NCN 442, our new route across the Cotswolds, as proposed because I knew very well that it was likely to open before long - not least because largely I identified the alignment and bid for the funding for it! And indeed it's now signposted and open: http://www.sustrans.org.uk/news/prime-minister-opens-new-section-national-cycle-network However, there are other proposed routes in the local area where there is no particular action underway at present to find funding or to fix issues identified with the route. For example, NCN 536 is a proposed route from Banbury (part of my patch) to Northampton, but: no funding has been identified, some physical works will be required before it can open, and the flow isn't currently deemed a priority. It's very unlikely indeed to open in the next two years, and consequently it isn't mapped on OSM. On occasion, mapping a proposed route can be actively dangerous and misleading. Sometimes a proposed NCN route will follow a busy road or rough terrain, or cross private land; fixing this will be one of the to-dos before the route can be opened. Showing it on a map, even as a dotted line, can encourage cyclists to venture into unsuitable conditions. (Yes, in theory caveat emptor, but I have encountered people who have been misled by such proposed routes showing on a map.) Obviously you'll make your own decisions, but I'd encourage you to follow similar principles for the USBRS project. Or in summary: OSM can be a little way ahead of reality... but not too far ahead. cheers Richard (making a rare break from my not-posting-on-mailing-lists rule) -- View this message in context: http://gis.19327.n5.nabble.com/USBRS-WikiProject-seeks-volunteer-mappers-tp5807660p5807703.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Completing the Appalachian Trail relation
Richard Welty wrote: Josh Doe wrote: I believe I saw SURFACE and CLUB which might be useful. i'm not keeping any of it, the source tag points back to the original data set and that should be sufficient. [...] i don't know that i see a mapping from the AT surface attributes to our surface tag, and an AT:surface tag would be largely ignored by OSM users If you can find a mapping from the Trail surface to OSM surface= tags, or even to tracktype= at a pinch, that'd be superb. I've just built a cycling router (using OSRM) and surface tags make _all_ the difference. They're something OSM greatly benefits from. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Completing-the-Appalachian-Trail-relation-tp5787477p5787521.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Steady increase in the number of mappers in the US
Clifford Snow wrote: We need publicity! Harry Wood is trying to recruit more volunteers for the Communication Working Group. You can e-mail him on o...@harrywood.co.uk . cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Steady-increase-in-the-number-of-mappers-in-the-US-tp5770307p5770444.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing US Bicycle Route tags
Kerry Irons wrote: Nathan, [...] Please advise when you will remove these tags. Nathan (NE2) has been given an indefinite ban from OpenStreetMap on account of his inability to work with others on what is a crowd-sourcing project: http://www.openstreetmap.org/user_blocks/347 It'll therefore fall to the rest of the US community to fix this (assuming the community agrees!). cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Removing-US-Bicycle-Route-tags-tp5764061p5764067.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Google maps source
Rick Marshall wrote: If we use bing imagery for tracing the road geometry, but Google Maps to discover the name of the road is it incorrect to use source=google? You are not tracing a road geometry from Google Maps, but you might be using it for other attribute data. _Do_not_copy_ANYTHING_from_Google_Maps_. From the terms you agreed to on sign-up: Your contribution of data should not infringe the intellectual property rights of anyone else. If you contribute Contents, You are indicating that, as far as You know, You have the right to authorize OSMF to use and distribute those Contents under our current licence terms. From openstreetmap.org/copyright: OSM contributors are reminded never to add data from any copyrighted sources (e.g. Google Maps or printed maps) without explicit permission from the copyright holders. From the Legal FAQ on the wiki: Other sources must not be used as the base of any data uploaded to OSM - whether maps, aerial imagery, or photographs such as Google Street View. This is because their licences and/or terms of use (contracts) forbid you to do so. Only sources with compatible licenses - such as US Government information released into the public domain - may be used as bases for adding OSM data. That means _any_ data from Google Maps. Not just street geometries, any data. If you have copied streetnames from Google Maps, please let the Data Working Group know (d...@osmfoundation.org) so that they can remove it from the database. Thanks. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Google-maps-source-tp5763947p5763957.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] User Cam4rd98 gun-jumping new highways + adding fictional alignments
Ian Dees wrote: This is what an account block is and it already happens. For those unaware of account blocks, you can read all those that have been imposed at http://www.openstreetmap.org/user_blocks . cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/User-Cam4rd98-gun-jumping-new-highways-adding-fictional-alignments-tp5763647p5763708.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OSM Data Quality
Martijn van Exel wrote: I think I just wrote half of one of my SOTM US talk. I think you just wrote half of mine too. ;) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-Data-Quality-tp5763578p5763648.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Bicycle Routes in KY, TN, AL, MS, and GA
Kerry Irons wrote: I would like to get in contact with the mapper(s) who put these routes into OpenStreetMap/OpenCycleMap and clarify this. We are always looking for enthusiastic folks who want to work on the USBR system but in this case putting detailed routes on maps is a source of confusion. Hello from over the pond... Here in the UK, several volunteers for Sustrans - the charity that runs the National Cycle Network - are involved with OSM (I'm one; Andy Allan, developer of OpenCycleMap, is another; but I think there's probably around a dozen in all). The upshot of this is that the routes as shown on OpenCycleMap are usually very accurate - on occasion, even, more up-to-date than the mapping on www.sustrans.org.uk itself. I'd encourage you and the ACA to follow this lead and find a small number of people who might be prepared to bring their detailed subject knowledge of the US Bicycle Route network to OSM. OSM always works best when it's populated by people with real knowledge, rather than the guesswork involved in armchair mapping. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-US-Bicycle-Routes-in-KY-TN-AL-MS-and-GA-tp5752481p5752606.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Anyone ever talked about adding more Land Ownership data to OSM?
Toby Murray wrote: I think it would be great to make more tools support more external data sets as opposed to dumping *everything* into OSM. Yep. Absolutely. To my mind this is one of the really nice things about TileMill. I'm currently playing with it to render (UK) maps that combine OSM and OS OpenData, and no import kittens have been harmed in the creation of the map. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Anyone-ever-talked-about-adding-more-Land-Ownership-data-to-OSM-tp5743315p5743361.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Addressing
brycenesbitt wrote: Is there evidence of Google using streetview plus OCR for addressing data yet? They've integrated it into ReCaptcha: http://techcrunch.com/2012/03/29/google-now-using-recaptcha-to-decode-street-view-addresses/ cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/US-Addressing-tp5738103p5738467.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address push part deux: tracking licenses, notifications, etc.
Jeff Meyer wrote: Ok... this is sort of an import question, but how do we / should we credit each imported item with a link or tie to the appropriate use statement / contributor? source= is just for showing your working. It is not a means of providing attribution. That should be done on the wiki /Contributors page and (in extremis, for national-level imports) on osm.org/copyright. If the attribution is really long, link to a sub-page off /Contributors. On objects, source=data.seattle.gov will do fine. Please don't repeat the mistake of the French cadastre import where every single fricking object has source=© Directeur General des Impôts La Plume De Ma Tante Mais Où Sont Les Neiges d'Antan or whatever it is. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Address-push-part-deux-tracking-licenses-notifications-etc-tp5738521p5738526.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Addressing
Jeffrey Ollie wrote: It looks pretty good from what I saw, with the obvious exception that newer homes aren't tagged. I'm going to clean up my code a bit and stick it up on github somewhere. If you chaps are all dead set on doing another massive TIGER import - hey, it's your funeral - could I at least urge a little caution on the practicalities of it all? Just having a look at the .osm file posted here, for example, the street names are all unexpanded: Washington St, Park Ave, Deer Run Ln, etc. There have been about 937 threads about expanding TIGER street names since the initial import and it would be a shame to fall into the same hole again. I'm also very very doubtful about the value of importing city, state and (!) country: if we don't have polygons for all of those already, then we really should. Importing n billion nodes into the States which all say hey, this is in the States will bloat the database and hammer download speeds for absolutely no gain whatsoever. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/US-Addressing-tp5738103p5738298.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Addressing
On 29/11/2012 22:46, Jeffrey Ollie wrote: None of the Iowa data that I am processing originates with the US Census or TIGER. Sure, I should have said big massive ---k-off import rather than TIGER. They both look the same from several thousand miles away I'm afraid. :) As Richard Welty said, the addr:city tag is pretty much required, as US addresses aren't defined by the boundaries of the city you live in (or don't live in for rural addresses), but the post office that delivers your mail. I can see not including the country or the state, do the various routing/geocoding engines take advantage of state/country polygons? I'm pretty sure they do. But regardless, the point is: they could. It's saner to fix (say) Nominatim than it is to import a really huge quantity of redundant data into OSM. If you're determined on doing this, then an extra few days to get it right won't hurt. You could pretty easily, I think, generate automated post office boundary polygons from the source data, rather than settling for addr:city. If it takes a few extra hours of coding, it's worth it; it'd make it _much_ quicker and easier to add a new house in the future. (One less thing to mistype.) Similarly, you might have to scratch your head a bit to write the code which expands St Andrews St into St Andrews Street and not Street Andrews Street. But it's worth it. Because if you don't do it, the 50 poor sods who write the turn-by-turn voiceover code are going to have to, every time they use your data. The specifics of what you have to do aren't really my point. I don't know much about the US and even here in Britain I don't have any personal use for addressing, so you shouldn't listen to me on the specifics. What's important is that the ideas get waved around in front of lots of people - and ideally not just on the US list - so that the hive mind can get to work and achieve the best result possible. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Operation Cowboy - Preaparing Thank you gift
!i! wrote: Hi, one last personal note on the mapathon and a big thank you (literally): http://www.openstreetmap.org/user/!i!/diary/18132 And thank you, too. I've always been sceptical about this sort of event - my vision for OSM is that we need more contributors with local knowledge, not more remote mapping - but in hindsight I think this, and MapRoulette, are showing some really interesting ways forward. By applying the OSM community to a problem in Mechanical Turk fashion, we're able to achieve much better results than an unthinking import or automated edit would do. Give the OSM community a task and it will carry it out much better than you'd imagine. There's lots we can learn from that. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Operation-Cowboy-Preaparing-Thank-you-gift-tp5737472p5738099.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What is the status of the Toolbox?
David ``Smith'' wrote: The banner at the bottom has some issues. Helpful for new and maybe intermediate users, but i'd like the option to turn it off. You can do that from the options dialogue (and it remembers your preference). I tried to put a little 'x' close box in there but, well, Flex had other ideas. Essentially the contextual help banner is there to (partly) answer the problem I clicked Edit, now what the hell do I do?. Also, it's an *editable* text field, which frequently captures keystokes that were meant for the tag pane. Yep. Cockup on my part. That was fixed at the same time as the movement stuff. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-What-is-the-status-of-the-Toolbox-tp5731560p5731712.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What is the status of the Toolbox?
Charlotte Wolter wrote: What is the status of the Toolbox? When will it be fixed? It is difficult to do any editing without those tools. And, whose idea was that banner? Did they ask anyone before they implemented it? Did they test to make sure it didn't break anything? Goodness me, Charlotte, you are hard work sometimes. I'm assuming you're referring to the Potlatch 2 toolbox, though you don't say. I am working on it Right Now and have been doing so for the last hour. I would have fixed it yesterday were it not for your opinionising of the trac ticket, which exasperated me sufficiently that I went and did something else instead. Right now I am trying not to get similarly exasperated... though clearly not with much success. :| Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] how to select overlapping objects in Potlatch 2?
Peter Dobratz wrote: Looking at the area in Potlatch 2, I can't figure out a way to select just one of the overlapping objects Select the shared node, press / . It'll select the other way. (If there are several sharing the node, keep pressing / until you get to the one you want.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/how-to-select-overlapping-objects-in-Potlatch-2-tp5724091p5724121.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Announcing Remap-a-tron
Martijn van Exel wrote: Let me know if it's useful / how it can be improved. Very very nice indeed. If someone could figure out a JavaScripty way to tell a currently-open Potlatch instance to jump to this location, rather than firing up a new instance each time, that'd be great. I'll happily do the P2 bit if someone smarter than me can do the Rails/JS bit. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Announcing-Remap-a-tron-tp5723115p5723496.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another random road reclassification
Richard Weait wrote: http://taginfo.openstreetmap.org/keys/expressway expressway=yes, seems to be a fringe tag at best. I believe our German friends use motorroad=yes for this. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Another-random-road-reclassification-tp5720723p5720800.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another random road reclassification
Paul Johnson wrote: Not quite. American expressways sometimes, but not always, have driveways, tracks and service roads connecting, German motorroads don't. Oh, sure. But you don't need me to tell you that slight national variations in the exact meaning of OSM highway tagging are nothing new. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Another-random-road-reclassification-tp5720723p5720804.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
Bryce Nesbitt wrote: I rather think the non-responders could have been a separate category, and their data could have been kept. Doesn't fly legally, sadly. You can't say I'm ignoring any rights on this item just because the rights-holder hasn't responded to my e-mails. That said, I did once live near a tiny village (population 41) that claimed to be Twinned with Paris on the basis that they'd written to Paris asking for a twinning, and received no reply. I guess that's a similar idea. http://en.wikipedia.org/wiki/Whitwell,_Rutland The license bot damage will take decades to recover from. Not at all. OSM has only existed since 2004, and the redaction affected 1% of the database globally. At a very conservative estimate it's 29 days' work (8*365*0.01); in reality, we _already_ have more nodes in the database than we did before the redaction started. Such is the rate at which the map is growing. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] LA part of the map essentially is unusable
Charlotte Wolter wrote: Got it. Thanks for the explanation. So, how do I load shapefiles into a separate layer? I need someone to walk me through it. How would I do that, if I wanted to get things like street names (and the other TIGER data)? I'll post a how-to at the start of next week - the new version of P2 needs to be deployed on the servers, but once that's done it'll be easy. And yes, it'll include pulling through street names. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-LA-part-of-the-map-essentially-is-unusable-tp5717315p5717484.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Redaction progress
Current state of affairs: - North America is mostly complete. The bot is still working in Los Angeles and Victoria (Canada). There are one or two failed or incomplete areas which are marked in red on the progress map; these are being retried individually. Haiti/Dominican Republic has been left out of this initial run to give a little more time for remapping. - Western Europe is also mostly complete. Some complex areas in Germany are still being processed. Redaction in Poland has paused after initially being processed with a whitelist missing (with the associated changes now reverted) and will resume as part of the final whole-world pass. - Belarus is complete. - Redaction is now underway in Australia, starting from the south coast. - Progress map link: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Please edit the To: line and make sure any follow-ups go to the relevant local mailing list only. :) cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
Toby Murray wrote: The good news is that TIGER data is still available to help in remapping. The TIGER 2011 tiles were recently discussed on this mailing list: http://wiki.openstreetmap.org/wiki/TIGER_2011 Indeed: and Ian, Andy and I have this afternoon briefly discussed making this available on a server so it can be pulled through into OSM by mappers. I've also done some work today on getting Potlatch 2 to load _big_ shapefiles, and tested it on the 55Mb shapefile for LA County. It's not fast, but it works. This too provides a really easy way to get the latest TIGER data into OSM, and once the new version is deployed I'll post some instructions here. Charlotte Wolter wrote: Do we think that the US map can have any validity if it doesn't include LA? Depends whether you visit LA I guess ;) , but assuming you do, let's roll up our sleeves and fix it. I don't think that one self-proclaimed viking deciding not to agree to the new licence completely damns OSM! cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-Fwd-Re-Post-bot-cleanup-tp5717309p5717318.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
jerjozwik wrote: is anyone else noticing some ways have a name, a one way direction, some other info, but no highway tag. so they dont actually render in potlatch 2. the only reason i noticed them way due to the oneway arrows being drawn on top of the satellite image. Everything's rendered in P2 - there's a special rule in the stylesheet that says if it's not been rendered, draw it as a plain black line. _But_ if you have the full satellite display, you might not be able to distinguish it easily. Use the Dim checkbox in the Background menu - that'll help you see it. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Post-bot-cleanup-tp5717182p5717408.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] LA part of the map essentially is unusable
Charlotte Wolter wrote: So, are you volunteering? Anyone else? I spent a couple of hours this morning reworking the P2 source code so that it can load the entire TIGER 2011 road files for LA County in one go without crashing. So yeah, that counts as volunteering to fix it in a way, I think. :) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-LA-part-of-the-map-essentially-is-unusable-tp5717315p5717409.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] LA part of the map essentially is unusable
On 19/07/2012 23:58, Charlotte Wolter wrote: Richard, I spent a couple of hours this morning reworking the P2 source code so that it can load the entire TIGER 2011 road files for LA County in one go without crashing. That's great, but will it overwrite work that we've already done? Also, is this something that works only in JOSM, in which case many of us couldn't use it? P2 = Potlatch 2. I'm the maintainer of the Potlatch code. I don't use JOSM unless someone threatens me with a cheese-grater. As I understand it, it's something that only works in Potlatch 2. :) P2's background layers feature allows you to have TIGER data showing up as a background layer, and to alt-click it to bring it through to the main map. There is nothing automatic about it: you choose what you want to bring through. It's a fast, efficient way of working with third-party data sources without the disadvantages of automated imports. As soon as the new version is available on openstreetmap.org I'll post further about how to use it (subject to being away from the computer this weekend). Also, I still don't understand why all the TIGER data was deleted on ways that were partially deleted. I just found a piece of a motorway link to I-5 where the bridge part was deleted, but the road still was visible in Potlatch. All the other TIGER data also was gone (luckily, I knew what it was). Why was that done? The redaction bot reverses changes made by decliners, _but_ it does not automatically undelete data that was deleted by decliners. Believe me, if it did the latter, the mess made of the map would be something to behold; there'd be random bits of road doubling up on existing highways here, there and everywhere. Neither option is easy but I'm certain that this one is the better. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] railway=abandoned and mapping things that are not there any more?
Peter Dobratz wrote: I'm trying to get a better understanding of the railway=abandoned tag and see what the community thinks about it. FWIW there's been a similar discussion on talk-gb recently. The consensus seems to be railway=abandoned for railways where there's still some physical trace (and you can see it from the air includes that!), and railway=dismantled used fairly sparingly where there's no trace left. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/railway-abandoned-and-mapping-things-that-are-not-there-any-more-tp5716334p5716341.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] railway=abandoned and mapping things that are not there any more?
Mike N. wrote: So they are present, and don't hurt anything. None of the 'standard maps' will bother to render them. A railway map could use them if it needed to. I delete them if they go through current buildings or parking lots also. Yes, that's a sensible attitude. I think it's also worth noting that what's on the ground is slightly in the eye of the beholder. I'm not really a railway archaeologist, but I do know quite a bit about old canals. There are places, even in redeveloped town centres, where the canal seems to be obliterated to the untrained eye; but if you know what you're looking for, the clues are there to see, even amongst the car parks. In those circumstances, a =dismantled tag makes sense. I guess one railway equivalent is where a bridge across a river has been removed. It's not railway=abandoned, it's clearly more than that. But there are usually bridge abutments still standing on either side, maybe even some stonework left in the river. Again, railway=dismantled seems appropriate there. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/railway-abandoned-and-mapping-things-that-are-not-there-any-more-tp5716334p5716356.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
Frederik Ramm wrote: I have been informed that I have no clue Actually the phrase I used was that Frederik clearly knows as much about Potlatch as I do about JOSM. (But I suspect more.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Fwd-OSM-dev-Licence-redaction-ready-to-begin-tp5715740p5716138.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2011 Data
Evin Fairchild wrote: I click the down-arrow next to where it says background, and then click Vector file. The http://a.tile.openstreetmap.us/tiger2011_roads/$z/$x/$y.png isn't a vector background, it's a standard tiled imagery background. You add these just by clicking 'Add' at the bottom of the imagery list, without going into the 'Vector file' dialogue. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/TIGER-2011-Data-tp5714968p5715143.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Special issues in LA remap
Steve All wrote: Now, when and how will this bot run? Over the entire planet.osm? In something like one-degree of latitude at a time swaths? (That's just a guess). Can you sense my frustration when I feel like I should be able to just go and find these things out (maybe in a big, all-encompassing License Change -- what you need to know, do and not do wiki page), but it really does appear to be a challenge? I believe the intention is to do a trial run over Ireland first. Ireland is almost completely ODbL/CT-compliant (http://odbl.poole.ch/ireland-20120601-20120531-poly.html) so it should prove a safe testing ground. This should hopefully be in early July, but we've not had a great track record on dates so far. ;) The decision on how to proceed for the rest of the planet will then be taken in the light of that. As with everything in OSM, our internal comms are limited by manpower and willingness to step up to the plate. Generally the people doing the work are too busy doing the work to write a wiki page... twas ever thus. So I'm telling you what I know, but there's always scope to get involved - even if it's just by stopping in at #osm-dev from time to time and finding out what's going on. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Re-Special-issues-in-LA-remap-tp5711500p5712872.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U.S. inland waterways
Nathan Edgars II wrote: I'm trying to do something like the European tagging: http://www.itoworld.com/map/24 But there they have some sort of international treaty that defines configurations. (puts day-job hat on) For users of a waterway, the European (CEMT) waterway classes describe, rather than define, the size of the limiting structures. They're information, rather than regulation. In other words, although a class Va waterway has a stated length of 110 metres, that doesn't mean that a river policeman will come and flag you down for taking a 115m boat along the river. It's very possible that the locks are (say) 120m long, and if you can get your boat through them, you're absolutely entitled to do so. This is particularly important at the smaller end of things where locks and bridges may be a zillion and one different sizes. (Here in Britain people routinely build boats to 60ft because there are certain locks that are 58ft 6in long... and if you put the boat in the lock diagonally, you can squeeze that little bit of extra accommodation. There are other locks that have subsided to become 1in too narrow for certain historic craft that would once have used the locks. And so on.) So the ideal is to tag each structure with its limiting dimensions, using the familiar maxwidth=/maxheight=/etc. tags. This is never going to be completely achieved, of course, because draught varies for each bit of the riverbed. ;) The next best thing is to tag the 'gauge' of a waterway - in other words, the largest dimensions that will fit through all the structures on that waterway. In Europe, tagging a waterway with the CEMT class would be a quick-and-dirty-though-not-particularly-accurate way of stating the gauge. (That said, the CEMT class would fit very well in the designation= tag.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/U-S-inland-waterways-tp5709017p5709046.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mapnik slower than usual?
Nathan Edgars II wrote: Is it just me, or are there more timeout magnifying glasses than usual? Is this due to the Osmarender server going down? AIUI there's some work going on to get local tile mirrors to serve requests. The London tile mirror (which currently serves the US) has had some initial load issues. The sysadmins know and are working on it. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Mapnik-slower-than-usual-tp5541521p5543634.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Mapnik slower than usual?
Charlotte Wolter wrote: I'm having that problem and still having several others in Potlatch 2. I can't add points. If I try to add a point, I can no longer highlight any ways. I have to save my work, go back to View and then return to Edit, which reloads Potlatch 2. Charlotte, we are trying to help you, but we can't do that without you coming up with some more information - as has been requested - and ideally using the proper bug-tracking system rather than the mailing lists. Just a mention of where this is happening would be good, as requested here: http://trac.openstreetmap.org/ticket/4275 Though it would really help if you could follow the guidelines in http://trac.openstreetmap.org/newticket : [start quote] * How to be a helpful bug reporter * Where you can, always provide steps to reproduce - in other words, a series of instructions that the developers can follow to reproduce your bug. The more you can do to pinpoint the problem, the more likely it'll be fixed. 1. Give any pertinent details of your system (operating system and version, browser and version, etc.). 2. If the problem is with a web page or web application, give its URL. If the problem is encountered with a particular set of data, say what (e.g. a location in OpenStreetMap). 3. Explain what you are doing, click-by-click. 4. Explain what you expect to happen. 5. Explain what is happening instead. [end quote] When it says click-by-click it _means_ click-by-click. Explain what you are doing _precisely_, so that a developer can follow the steps you are taking. When you say I can't add points that could mean a million things - by dragging-and-dropping from the left-hand panel? By shift-clicking in a way? By double-clicking on the page? Who knows. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Fwd-Re-Mapnik-slower-than-usual-tp5544499p5544528.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Mapnik slower than usual?
Have you not checked back at the tickets to see followup comments? On 7 Mar 2012, at 16:58, Charlotte Wolter techl...@techlady.com wrote: Richard, I have posted tickets twice to TRAC in the last two days, and have no communication about my issues. What requests are you referring to? --C At 07:50 AM 3/7/2012, you wrote: Charlotte Wolter wrote: I'm having that problem and still having several others in Potlatch 2. I can't add points. If I try to add a point, I can no longer highlight any ways. I have to save my work, go back to View and then return to Edit, which reloads Potlatch 2. Charlotte, we are trying to help you, but we can't do that without you coming up with some more information - as has been requested - and ideally using the proper bug-tracking system rather than the mailing lists. Just a mention of where this is happening would be good, as requested here: http://trac.openstreetmap.org/ticket/4275 Though it would really help if you could follow the guidelines in http://trac.openstreetmap.org/newticket : [start quote] * How to be a helpful bug reporter * Where you can, always provide steps to reproduce - in other words, a series of instructions that the developers can follow to reproduce your bug. The more you can do to pinpoint the problem, the more likely it'll be fixed. 1. Give any pertinent details of your system (operating system and version, browser and version, etc.). 2. If the problem is with a web page or web application, give its URL. If the problem is encountered with a particular set of data, say what (e.g. a location in OpenStreetMap). 3. Explain what you are doing, click-by-click. 4. Explain what you expect to happen. 5. Explain what is happening instead. [end quote] When it says click-by-click it _means_ click-by-click. Explain what you are doing _precisely_, so that a developer can follow the steps you are taking. When you say I can't add points that could mean a million things - by dragging-and-dropping from the left-hand panel? By shift-clicking in a way? By double-clicking on the page? Who knows. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Fwd-Re-Mapnik-slower-than-usual-tp5544499p5544528.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Adding Tiger 2011 Data
Nathan Edgars II wrote: What do you mean by red circles with no tag? I think that's probably dupe nodes in P2. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Adding-Tiger-2011-Data-tp5526409p5526452.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remapping tips
andrzej zaborowski wrote: And there are real people using OSM in many other fields. What I mean I think we all know what you _mean_, whether or not we agree with it. What puzzles me is what you're trying to _achieve_. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Remapping-tips-tp5461596p5463663.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
Mike N. wrote: Everyone will certainly enter name=Xyz Rd for their first edit. The JOSM validator will pick this up, but I don't remember if Potlatch 2 would notice that. No, it won't. P2 will get inbuilt QA one day, but only when someone has the time to do it _properly_. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Imports-information-on-the-wiki-tp7144553p7190384.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Now you can see how much vandalism the OSMF will carry out on April Fools
Grant Humphries wrote: Can anyone expand on that or point me in the direction to find more information about this? http://wiki.openstreetmap.org/wiki/Quick_History_Service#Changeset_Overrides should be right. I'm sure Andrzej can supply more details if required. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Now-you-can-see-how-much-vandalism-the-OSMF-will-carry-out-on-April-Fools-tp7087232p7095074.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
