Re: [Talk-us] Mapping rail trails
* stevea [2019-07-11 17:38 -0700]: > I know it seems "like it just makes sense" to combine Maryland and DC > relations, but there are rather deliberate reasons to keep these > separate. One is state-level, the other is federal-level (is one), but > the "state at a time for route relations" is a fairly well-established > method of tossing things into buckets. We do it with bike routes, > motorways and more. However: The C Trail is contained within the C National Historic Park, which is owned by the National Park Service, so it's all really at the same (federal) level. The "state at a time" pattern, as I have always understood it, exists to keep vastly distant objects from being linked with each other. It makes it much less likely for someone, say, updating I-95 in Florida to get an editing conflict with someone else who made a change in Massachusetts. State borders provide convenient locations for the division of overly-lond relations. It's also a rule of thumb; I've seen plenty of cases where short distances in multiple states are aggregated into a single relation. (e.g. there's only one relation for US 340, although it spans MD, VA (in two sections), and WV.) Since there's only a short section of the C Canal Trail in DC, I don't really see the harm in putting all of its ways into a single relation. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Anyone who has never hacked sendmail.cf has no soul. Anyone who has hacked it twice has no brain. -- Peter da Silva --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mapping rail trails
* Richard Fairhurst [2019-07-11 01:56 -0700]: > It would be good to have a distinct C Canal Trail relation over and > above the USBRS 50 relation, for example. You mean aside from these? https://www.openstreetmap.org/relation/1392951 https://www.openstreetmap.org/relation/9773990 I suppose it is a little silly to have a separate DC portion; I could just go combine them into a single relation. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The Old Man and the Sea LITE(tm) by Ernest Hemingway An old man goes fishing, but doesn't have much luck. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
* Phil! Gold [2019-03-08 17:44 -0500]: > https://gitlab.com/asciiphil/osm-shields Oops, that's the master branch, which doesn't have the changes. You need to look at the svg branch: https://gitlab.com/asciiphil/osm-shields/traa/svg -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- #if _FP_W_TYPE_SIZE < 32 #error "Here's a nickle kid. Go buy yourself a real computer." #endif -- linux/arch/sparc64/double.h --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
* Kevin Kenny [2019-03-08 14:25 -0500]: > On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel wrote: > > > > I agree that a local US OSM map with a *subtly* adapted rendering would be > > fantastic. Phil Gold did some interesting work years ago on rendering US > > style highway shields taking into account (sometimes crazy) route > > concurrency > > (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B > > - note that this is based on years-old data and probably pre-carto-switch > > stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more > > divergent from the main map style, but another great example of initiatives > > around custom map rendering coming out of the US community. > > I've borrowed ideas (and some limited amount of code) from both of > them in doing my experimental rendering [snip] > The chief roadblocks to scaleability are that the graphics are > generated in what amounts to a batch process, taking several minutes, [snip] > Then there's the issue that the graphics for individual shields are > being stored in PNG, which is rendered in a batch process that takes > typically several minutes (so could not cope with minutely updates). I started work last year on a better system that generates SVGs on the fly from OSM data, so it doesn't need the pregeneration step. I got bogged down with other things before I quite finished, but it's mostly there. (There are just a few Canadian routes left to convert; I was having difficulty finding official specs for their signs.) I don't think this is really documented yet, but I now support four different sign styles, passed as the `style` parameter to the Python rendering functions: * "generic" uses a standard, generic style for every US state and county, disregarding their individual styles. * "guide" matches the styles used on highway guide signs. This is now the default, since it seems most fitting to map rendering. * "sign" looks like the roadside reassurance markers. * "cutout" is a modification of the "sign" style to remove dark background areas. This used to be the default with my old system. Anyway, the code is here: https://gitlab.com/asciiphil/osm-shields Hopefully at some point I'll find time to finish up my changes. (And, ideally, merge in all of the extra shields you and Minh have put together.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- What computers do Daleks use? X-TERMINALS, X-TERMINALS! --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Representing census-designated places (CDP), Census County Division (CCD), etc
* Nelson A. de Oliveira[2016-04-28 16:24 -0300]: > Do you represent [CDPs] (and maybe other statistical boundaries) in OSM? > If yes, what are you using? (boundary=?, border_type=?, etc) As people have indicated, practices vary. I live in a region where very few named population centers have legal administrative boundaries[0], so a) we have a lot of CDPs, and b) the CDPs are useful approximations of the geographic extents of places that people refer to by name on a day-to-day basis. What I often do (because I've seen others do it) is take the CDPs that were imported from the US Census's TIGER dataset and change them from boundary=administrative to boundary=census. (I also drop the admin_level=8 tag.) Most of these places also have a place=* node, which I don't usually merge with the CDP, mostly for fuzzy personal reasons like, "The CDPs are useful enough to keep around but I don't always feel like they're right *enough* to supplant a place node at the rough geographic center of the place." [0] In Maryland, the counties tend to perform a lot of administrative functions like road maintenance, fire and police services, and school operations. Consequently, there's not a strong need for most communities to incorporate so most don't. Boundaries between adjacent populated places are very fuzzy and driven a lot by what the people who live there happen to say about themselves. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- There's a frood who really knows where his towel is. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Strategy for Naming Parts of a Large Park
* Elliott Plack[2016-03-01 14:49 +]: > [Patapsco Valley State Park] consists of several nine or so areas (2) > spread out over 30 miles of the Patapsco River valley. Some of the parts > are contiguous, others not. The sub-areas also do not have (or do not always have) well-defined boundaries. The park itself is well-defined (and already has a multipolygon border), but most of the sub-areas would either be nodes or areas whose edges aren't really authoritative. At the moment, there's a single multipolygon for the entire state park, tagged leisure=park and boundary=protected_area, protect_class=5. The individual areas are generally nodes tagged leisure=park with names like "Patapsco Valley State Park - McKeldin Area". The whole park-in-a-park thing feels a little off to me, but it does get the names rendered on the default map. :-/ (Elliott knows all this, but I thought it might be useful information for the discussion.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Join the non sequitur society. We may not make sense but we do like pizza. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Best practices for coastline to Inland Bay / River transition
* Elliott Plack[2016-01-07 20:12 +]: > What are the current accept[ed] best practices for determining where to "cut > off" the coastline and to begin a river or bay type feature? The wiki seems > to be in disagreement about this, and I've read chatter about switching to > ocean polygons. I'm not sure I've seen a best practice, really, but I have in the past closed off rivers at their mouths and then tagged their (multi)polygons waterway=riverbank, tidal=yes. (Sometimes it can be difficult to tell where a river stops being tidal, but at least the Potomac doesn't have that problem.) My reasoning is essentially along the same lines as what to do when one river flows into another: at some point the smaller river ends and you could do worse than to draw a line across the mouth of that river and say, "Everything on this side is River A and everything on the other side is River B". Likewise, at some point, the ocean stops being the ocean (or the Chesapeake Bay stops being the Chesapeake Bay), so why not at the mouth of the river? Bays are a little more problematic, as there's not always as obvious a mouth as for a river, plus features like bays and coves can coexist with other features like rivers.[0] I usually leave bays as point features unless there's a really obvious delineation between them and everything else. I actually went through the work of cutting the Potomac off from the coastline of the Chesapeake Bay and turning it into riverbank multipolygons a few years ago, but JOSM crashed and lost my work before I was able to upload it and I felt too depressed to go back and redo everything. I believe I have since gone back and put in *some* riverbank multipolygons at the upstream end of the tidal region of the river. [0] I know according to some points of view, the entire Chesapeake Bay is just the lowest part of the Susquehanna River, but I'm pretty comfortable leaving the Bay as coastline. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- "I don't trust dreams." "They said they weren't dreams." "So? Dreams lie." -- "The Kindly Ones", Neil Gaiman --- -- ___ 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
* Jack Burke burke...@gmail.com [2015-06-22 08:32 -0400]: On June 22, 2015 2:46:36 AM EDT, Bryce Nesbitt bry...@obviously.com wrote: tiger:reviewed=no Most of the well reviewed Tiger I see still has this tag. People don't know to delete it. Usually I change it to =yes instead of just deleting it. The main reason is I frequently use ITOworld maps to review the county I live in to find unreviewed roads, and I like the color pattern better that way. Hm. Maybe I'll start doing that. I also use tiger:reviewed=position to signify that I've armchair-mapped the way to align with aerial imagery but haven't yet been out to verify the road name. (Details about my use of this tag are in this diary entry: http://www.openstreetmap.org/user/asciiphil/diary/16247 ) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- NOTICE: Anyone seen smoking will be assumed to be on fire and will be summarily put out. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing parks and schools for Anne Arundel County MD
* Gregory Arenius greg...@arenius.com [2014-05-30 00:52 -0700]: The only other thing that stuck out to me about the data was the B A trail. You have a polygon for the trail which is awesome but I would also add in a properly tagged linear way. It will make it possible for routers to use it as well as rendering properly. The trail is already in OSM as a linear feature. I think the import process should be semi-manual, though, as the landuse polygons need to be integrated with existing OSM data. (e.g. there are a number of residential areas abutting the BA Trail, so the edges of those should be merged, rather than left overlapping each other.) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State ref tags on ways
* Elliott Plack elliott.pl...@gmail.com [2014-03-28 02:53 -0400]: Interesting note about this in Maryland. My friend Mike showed me that some mappers have been using the *county* route numbers on some county roads in Maryland. Since Maryland counties don't sign their route numbers[0], they're using unsigned_ref=, not ref= in their way and route relation tagging, right? [0] In any county I'm directly familiar with, at least; I don't go to southern Maryland much, and I don't usually venture far outside the US 50 corridor on the Eastern Shore. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NAIP Imagery Servers -- Need Assistance Setting Up in JOSM
* Kam, Kristen -(p) krist...@telenav.com [2014-03-24 17:26 +]: The other week, I came across the directory of USDA's WMS NAIP Image Services (by state). QGIS renders the images with no problem, but it appears to fail in JOSM. If it helps, OSM-US hosts a tile proxy for the USGS-hosted NAIP imagery. It's documented on the US Imagery page: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers/Imagery The best layer to use is probably the USGS Large Scale Imagery, which uses NAIP at low resolutions and switches to the USGS High Resolution Orthophotography at higher resolutions. The JOSM configuration for it is: tms:http://{switch:a,b,c}.tile.openstreetmap.us/usgs_large_scale/{zoom}/{x}/{y}.jpg ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State ref tags on ways: Use of unique ISO/ANSI/USPS 2-letter state codes in RELATIONS as well as WAYS?
* Toby Murray toby.mur...@gmail.com [2014-03-12 00:33 -0500]: I went and verified some things about bannered routes. It looks like the current shield rendering looks for network=X:Y:Modifier. So for example the US 50 truck route in Cincinnati is network=US:US:Truck and ref=50. [snip] Looking around it looks like the other convention that has some decent use in the database (but is not currently supported by any renderings) is to add a modifier=Truck/Business/Spur/etc tag. I believe the wiki recommends that bannered routes get a modifier tag in addition to having the modifier in the network tag, so US 50 Truck is network=US:US:Truck, ref=50, modifier=Truck. The idea is that data consumers can get the parent route network by subtracting modifier from network. (But data consumers that don't care about parent route networks, like the shield rendering, don't have to know about the modifier tag.) I don't know of any data consumers that make use of the modifier tag currently, but there weren't many consumers making use of route relations in general before the shield rendering. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The truth is not free. It's that simple. If you change the truth, it is no longer true - so the truth is not free! -- Jules Bean about freeness of documentation --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
* Alex Barth a...@mapbox.com [2014-03-13 10:26 -0400]: http://www.openstreetmap.org/user/lxbarth/diary/21221 This is really similar to the discussions that periodically happen in the open source software community over whether share-alike licenses like the GPL or open-use licenses like the 3-clause BSD license are better. I usually end up on the side of share-alike for reasons best summed up by a friend of mine who once said, The GPL restricts your freedom to be evil. The BSD license doesn't. I think that if your goal is to have as many people as possible using your data, you're best off choosing open-use or public domain licensing. (Richard Weait and I chose to go with CC0 and PDDL for the data in the shield rendering so as to allow for as much variance of reuse as possible. Similarly, it makes sense for US federal government data, because their mandate is to be as useful to US citizens as possible.) If, however, you want to foster a community around a larger scale project, I think share-alike is a better path to take. If OSM switched to public domain licensing today, there would almost certainly be more people using and benefiting from today's OSM data. Google in particular would probably make OSM data part of its data; they already merge numerous public domain datasets into their proprietary dataset. That would make Google the better choice for a lot of people than plain OSM data, and you can even edit Google's data through their Map Maker program. From there, I suspect that Map Maker would attract more people that might otherwise have ended up contributing to OSM, which would hurt community growth and benefit Google at the expense of all the other OSM data consumers. In my opinion, the single biggest thing that makes OSM valuable is the community of people contributing to it, and the license on the data needs to reinforce that community, not allow proprietary data uses to splinter it. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- lately my mania has been mega-lo-mein-ia, which is to say i believe the plate of noodles is larger than i am. -- elysse --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Question about incorrect data for an administrative area
* Jay Boyer bo...@snhdmail.org [2013-10-10 13:34 -0700]: Enterprise is an unincorporated town. But Enterprise is actually part of Las Vegas and all of the addresses within Enterprise are Las Vegas addresses. Enterprise is this area: http://www.openstreetmap.org/browse/relation/170132 There are a couple of things going on here. First, if Enterprise does not have its own government, it probably shouldn't be boundary=administrative. I've seen people use things like boundary=census for unincorporated towns where the town boundary is a CDP from the US Census data import. Second, place=locality is for locations that are not associated with a population center. Based on my understanding of the tags, for a place that is considered to be within a place=city, you should use either place=suburb (for major or notable city divisions, which it sounds like Enterprise is) or place=neighbourhood. Nominatim will order either of those tags hierarchically with the city-tagged place, so address lookups will work for both Street Name, Enterprise, NV and Street Name, Las Vegas, NV. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Current status with highway shields?
* Evin Fairchild evindf...@gmail.com [2013-10-09 19:54 -0700]: I emailed Phil Gold (creator of the awesome shield rendering) about this almost a month ago, but he never responded so this hasn't been fixed. Er, sorry about that. I've been extremely busy for about the past two months, and probably won't really have time to dedicate to the shields for at least another month or two. I did start experimenting with carto a while back, so when I have time for the shields again, that'll be a high priority item since, based on my experience so far, I don't think it'll be too hard to work in to the new stylesheet. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shields are up!
* Toby Murray toby.mur...@gmail.com [2013-07-28 22:38 -0500]: http://tile.openstreetmap.us/osmus_shields/preview.html Awesome! Thanks for all your work in making this happen! ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shields are up!
* Richard Welty rwe...@averillpark.net [2013-07-29 08:17 -0400]: one thing to consider in NY, though - not all counties use the yellow-on-blue pentagonal County Route signs. right now it's automagically using that style shield for all county routes. should we deal with this or let it go? I'd prefer to deal with it. I'd like the shields to match actual road signs as much as possible. If you can get me a list of what New York counties use which sign styles, I'll work on getting the rendering to match them. For what it's worth, Minh Nguyen has been working with other Ohio mappers to both get Ohio's county routes into OSM and to document the signage (and the tagging they're using) at http://wiki.osm.org/wiki/Ohio/Route_relations/Networks ; I would not at all object if people put together similar references for other states with diverse county sign styles. :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shields are up!
* Michal Migurski m...@teczno.com [2013-07-29 00:40 -0700]: I wonder if this would be helpful: I've been generating weekly generalized datasets of route relations. http://openstreetmap.us/~migurski/streets-and-routes/ The tiles take a little while to render, so I wonder whether using an intermediate data set would cut some corners while reducing repeat labels? One of my goals with this project was to make a rendering that works off a minutely-updated rendering database. It could probably be adapted to work off postprocessed datasets like your generalized route relations (though I don't know (because I haven't looked at your data) whether shield clusters would be easily derivable), but I think that having a minutely-driven rendering is really beneficial to mappers working on data the rendering highlights. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shield rendering and detours; tagging nicknames?
* Paul Johnson ba...@ursamundi.org [2013-07-13 18:52 -0500]: OK, wonder if we can get orange detour banners for routes as well? Example relations can be found in the downtown Tulsa area, which has an interstate (244), two US routes (64, 75) and an Oklahoma state highway (51) detoured through the end of next year. I'll see about adding stuff under US:I:Detour, US:US:Detour, and, I guess, US:OK:Detour. I've also finally gotten around to adding relations for the LL Tisdale Parkway ( http://www.alpsroads.net/roads/ok/cool_j/) and the Gilcrease Expressway ( http://www.aaroads.com/shields/show.php?image=OK19720071) to test out city route shields. I'll add them to the list of routes needing shields. What network are you using for those? Also, what would be an appropriate tag for a completely informal name for something that is getting uptake by way of traffic reports? Tulsa's Inner Dispersal Loop has been called the Inner Detour Loop by some reporters. Based on http://wiki.openstreetmap.org/wiki/Names , I'd say loc_name=. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- If the beautiful princess that you capture says, I'll never marry you! Never, do you hear me, NEVER!!! say, Oh well, and kill her. -- Evil Overlord's Handbook, entry 53 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Releasing my data into Public Domain
* Elliott Plack elliott.pl...@gmail.com [2013-07-18 14:25 -0400]: Question to you: On our website, we are uncertain as how to say, The data is public domain. Can you all provide examples of other sites that provide data that has been imported into OSM? I don't know of any large sites using it, but this seems to be exactly the sort of thing that the Open Data Commons' Public Domain Dedication and License was intended for: http://opendatacommons.org/licenses/pddl/ The PDDL extends CC0 to datasets in the same way that the ODbL extends CC-BY-SA. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* James Mast rickmastfa...@hotmail.com [2013-07-15 00:36 -0400]: Man, there are TONS of bannered routes in GA. It might take forever to find out all of them, even with using GA's own maps to find them. Well, I wrote a tool[0] that looks at the rendering database and gives me a list of route relations without shields. In the worst case, someone would add a new bannered route and it would sit unrendered until I looked at the missing shields page and saw I needed to add it. [0] http://bazaar.launchpad.net/~asciiphil/osm-shields/trunk/view/head:/show_missing.py ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* James Mast rickmastfa...@hotmail.com [2013-07-13 20:46 -0400]: In GA, it seems you're not supporting the US:GA:Connector network. I do support US:GA:Connector, but I didn't have an entry for Connector 40. (I do now. :) ) I an effort to reduce the amount of time needed for shield generation, I tend to specify only the specific bannered routes I know about, either from personal experience, Wikipedia, or looking at OSM data. I'm pondering a change to the bannering code that would handle most cases more dynamically (but not for Georgia, since they don't actually use banners for their bennered routes...). -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The ring needs another token. -- BOFH excuse #129 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* James Mast rickmastfa...@hotmail.com [2013-07-11 14:02 -0400]: I know that there is a US 1-9 in NJ, but this error is showing up in NC. ;) Oh, wow. That *is* a bug. I've got to figure out how to handle it, but here's what's going on: Those ways (take http://www.openstreetmap.org/browse/way/11177 as an example) are members of three relations: NC Strategic Highway Corridor 34, US 1, and US 1 Bypass. (Like the other case that came up recently, I question whether it's *really* both US 1 and US 1 Bypass.) US 1 Bypass is tagged as network=US:US, ref=1, modifier=Bypass, so the rendering treats it as a duplicate of US 1. The consolidation algorithm I wrote for US 1-9 is a little naive; it matches against US 1 and US 9 and if it gets two matches, it substitutes in US 1-9. The duplicate US 1 relations give it two matches, so it does the substitution. I'll have to think a bit about how I want to address this bug. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* Phil! Gold phi...@pobox.com [2013-07-11 15:32 -0400]: * James Mast rickmastfa...@hotmail.com [2013-07-11 14:02 -0400]: I know that there is a US 1-9 in NJ, but this error is showing up in NC. ;) Oh, wow. That *is* a bug. And now it's fixed. :) The replacement code will only kick in if both parts of the precondition are met. This does raise a thought for me. I'm going to see if I can convince my code to spit out a shield for every relation, even if two of them are duplicates of each other. That will better highlight cases like this where two overlapping routes have the same apparent definitions. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
* James Mast rickmastfa...@hotmail.com [2013-07-09 01:40 -0400]: So, does anybody else have any more comments on how we should deal with tagging these Future Interstates? Given that previous list consensus was for tagging of the form: network=US:I:Future ref=number modifier=Future and that only one person offered a variant opinion this time around, I'd recommend tagging as above. Also, from your earlier emails, I have future interstates 26, 73, 74, and 840. Are there any others? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
* James Mast rickmastfa...@hotmail.com [2013-07-10 08:59 -0400]: There is one other. I mentioned it in my e-mail from yesterday (07-09-13). That is I-295 in Fayetteville. Okay, I've got that one in my rendering now, too. And to be honest, I thought some people wanted the :Future part dropped out and just put in the modifier area. This time around, one person suggested that. (In previous discussions there was a second opinion along those lines, but he's not on this list at the moment.) In the past, everyone else who's voiced an opinion has gone for the US:I:Future style of tagging, and no one else even chimed in this time. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* James Mast rickmastfa...@hotmail.com [2013-07-10 09:22 -0400]: I could fix the PA Turnpike relation with the US:PA:Turnpike network tag in a moment. Would that work instead of just fixing the name tags for both directions? That wouldn't affect my rendering as it currently stands. The rendering, right now, will only make a shields for a relation with the exact name Pennsylvania Turnpike. I only split it up because it was getting close to 1,000 ways and thought it would be easier to edit in the future having two smaller relations, one for each direction. -James Yeah, the same reason we split national routes on a state-by-state basis. The practice of putting stuff like I-95 (VA) in the name tag on those doesn't interfere with my rendering because those relations have ref tags, even though that's not really the name of the route. What we really need is a tag like name:relation that the editing tools can use for labeling things in their UIs when we want something more descriptive than precise use of the name tag can give us. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Well, what IS the song, then? said Alice, who was by this time completely bewildered. I was coming to that, the Knight said. The song really IS 'A-SITTING ON A GATE': and the tune's my own invention. -- _Through the Looking-Glass_, Lewis Carroll ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* Richard Welty rwe...@averillpark.net [2013-07-10 09:58 -0400]: an NJTP shield is probably appropriate. the turnpike is _not_ precisely I-95. I think I was unclear in my question. I have a New Jersey Turnpike shield that I want to use. My question is: should the route relation for the New Jersey Turnpike be tagged ref=NJTP or should it have no ref tag at all? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
* Paul Johnson ba...@ursamundi.org [2013-07-10 10:16 -0500]: I don't think we hit a consensus, did we? Seems like we were talking about whether having a modifier tag or not, and if not, including the banner in the network. As I documented at http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tt5612357.html#a5640994 , I think there's definitely a consensus around putting the banner in the network. I don't recall anybody proposing doing both (which seems redundant on multiple levels). I don't recall a specific discussion about whether to use the modifier tag with the banner already in the network tag, but the wiki (at http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Tagging_with_relations ) implies that the modifier tag should duplicate the banner present elsewhere, and I've seen the practice in OSM data (from at least NE2, but I'm reasonably sure I've seen other people tagging in this way, too). Separately from the practice that I've seen, I think that having the modifer separate as well as in the network tag allows data consumers to easily work back to the root network while still preserving the uniqueness constraints for consumers that only process the network and ref tags. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* James Mast rickmastfa...@hotmail.com [2013-07-10 10:44 -0400]: http://www.openstreetmap.org/browse/way/172380289 There are some interesting things going on here. Is this road really part of both US 21 and US 21 Bypass? That seems weird to me, but if someone says that's how the road's signed I'll believe it (see: US 1-9 signage...). Also, the map really ought to show bypass shields for the roads that are part of US 21 Bypass.[0] My rendering is not doing so because US 21 Bypass has network=US:US (not network=US:US:Bypass), so it's treated as mainline US 21. [0] Like US 341 Bypass here: http://elrond.aperiodic.net/shields/?lat=32.4739lon=-83.7315zoom=14 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
* Paul Johnson ba...@ursamundi.org [2013-07-10 10:28 -0500]: On Wed, Jul 10, 2013 at 2:18 AM, James Mast rickmastfa...@hotmail.comwrote: Also, do you guys think for the PA Turnpike XXX routes, that the network tag for them should be US:PA:Turnpike That's how I've been handling the Oklahoma situation: US:OK:Turnpike. Yep: http://elrond.aperiodic.net/shields/?lat=34.55064lon=-96.94071zoom=13 :) I only see two US:OK:Turnpike routes in the database at the moment, and the Cherokee Turnpike suffers from the same issue as the PA Turnpike has currently; my rendering doesn't understand name=Cherokee Turnpike (eastbound). I'm still not sure what the best way to handle that is. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging a super-two highway (trunk or motorway?)
* Toby Murray toby.mur...@gmail.com [2013-06-30 03:39 -0500]: So then we come back to the question of what exactly is trunk if it isn't used for these kinds of roads? I've thought of them as something like really major but not Interstate-grade roads. Primary roads are main roads, obviously, but trunks have better throughput. I mentioned MD 90 earlier; in the same region is the easternmost part of US 50 which is a divided highway with at-grade intersections and periodic (but not frequent) traffic lights. It's designed to get a lot of people to and from Ocean City, MD in an efficient way. I think it definitely fits as a trunk. I think most of the things I would consider trunk are divided, but I have seen undivided roads that others have tagged trunk and thought, Yeah, that makes sense there. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- #define FALSE 0 /* This is the naked Truth */ #define TRUE1 /* and this is the Light */ -- mailto.c --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
* James Mast rickmastfa...@hotmail.com [2013-06-26 22:34 -0400]: I thought the modifier would be the type of Business route? Remember, we do have Business Spurs and Business Loops for Interstate highways. Sometimes both types in the same city. Every Business Interstate is signed as either a spur or loop, so I would consider the full modifier to be either Business Spur or Business Loop. For lack of a better approach, I set up the shield rendering to process them with network values of US:I:Business:Spur and US:I:Business:Loop. I guess the value of the modifier tag could be either Business:Spur or Business Spur. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- $a='X'; print map \$a='$a'; $_, q($_), q(print map \$a='$a';$_, q($_)) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Future Interstate Relations
* Paul Johnson ba...@ursamundi.org [2013-06-26 23:25 -0500]: Looks like the spur extends the loop, I'm not sure I'd differentiate them in modifier, but might in the description. They're signed differently, so I think that makes them distinct enough to be treated differently. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Photons have neither morality nor visas. -- David Farber --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Route Relation Tagging, again (was Re: ref tags)
* Paul Johnson ba...@ursamundi.org [2013-06-24 09:11 -0500]: network=US:I modifier=Future * James Mast rickmastfa...@hotmail.com [2013-06-25 00:15 -0400]: Now, I'm going to initially use the following to tag the Future segments inside of relations: network=US:I:Future However, somebody else suggested this: network=US:I modifier=Future Which do you guys think would be the better way to go? There's been discussion about how to tag the relations for bannered routes in the past. My understanding of the list consensus, as I summarize in this previous email: http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5640994.html is that Future Interstate 26 should be tagged as follows: network=US:I:Future ref=26 modifier=Future However, in a Google Hangout last week, Paul indicated a desire to reopen the discussion on tagging bannered routes, so here we go: There are basically three options for tagging bannered routes. I'll use Future I-26 as an example here, but the principle applies equally to any other routes. Option A (network-classification-per-banner): network=US:I:Future ref=26 modifier=Future Option B (banner-in-ref): network=US:I ref=26 Future modifier=Future Option C (banner-in-modifier): network=US:I ref=26 modifier=Future In my opinion, either option A or option B should be used. Because a veriety of people with a variety of OSM experience edit OSM data, I think it's important to consider how damaged or incomplete data will be treated by data consumers. In any of the above cases, a data consumer that only sees or understands the ref= tag (e.g. something that was written to handle ways and is now looking at a relation) will not get a complete picture, but also won't get a wrong impression (thinking that I-26 is US 26 or something similar). Furthermore, the network/ref tagging has been pretty well established on the wiki and in general usage for some time now. If a data consumer only sees or understands the network and ref tags, both options A and B will give it a complete picture of the route, but option C will be incorrectly interpreted as the main I-26. I think that's a pretty strong argument against option C. In programming or database design, one strives to eliminate all duplication, but in a project like OSM I think a little duplication of data serves as useful redundancy. Note that if the modifier tag is present, both options A and B can be processed to remove the redundant information if that's desired. I think the choice between options A and B is more of an aesthetic one. What matters is that there is a consensus on what the tagging is. I think in previous discussions more people were tipped toward option A because it makes the decision of when to use a different network easy, because network essentially means different road sign. Option B has a little more grey area, since there were people (well, mostly NE2) saying things like alternate and business Interstates are clearly not part of the Interstate Highway System, but alternate and business US Highways are clearly part of the US Highway System (paraphrase from [1] and [2]). [1]: http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5636639.html [2]: http://gis.19327.n5.nabble.com/Use-of-ref-tag-on-state-highways-tp5285587p5285594.html As I said before, my understanding of the list consensus in previous discussions is for option A and that's what my renderer understands (see [3]). If you have an opinion on what we should be using (whether it's one of options A, B, or C above or some other system), I guess this is the place to voice that opinion. [3]: http://elrond.aperiodic.net/shields/supported.html ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging a super-two highway (trunk or motorway?)
* Paul Johnson ba...@ursamundi.org [2013-06-25 09:40 -0500]: There seems to be some disagreement on how to handle the super-two (or super-four s California has a few of) highways. [snip] I'm under the understanding that the consensus for a motorway would be fully multiple (at minimum 2) carriageway with limited access, whereas a trunk would be any motorway that doesn't meet that criteria (intersections, single carriageway, etc). That matches my understanding. Maryland Route 90 seems to be what people would call a super-two and, although parts of it are divided, other parts have no physical separation. For most of its length, it has no at-grade intersections. When I was doing TIGER cleanup in that area, I decided that highway=trunk fit better than highway=motorway. (Although NE2, somewhat unsurprisingly, decided that he knew better and has retagged it highway=motorway with oneway=no on the undivided sections.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* James Mast rickmastfa...@hotmail.com [2013-06-22 20:04 -0400]: Yep, here's picture proof that I personally took a few years ago of a Future I-26 shield: http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg Alright. I'll add Future Interstate shields to my todo list. Unless everyone agrees on something else, I'll plan to key them off a tag of network=US:I:Future . ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Hamlets!
* Serge Wroclawski emac...@gmail.com [2013-06-21 09:17 -0400]: During the TIGER import, small neighborhoods were imported as hamlets. I tend to think of the GNIS hamlets as small places-where-people-live. Around my section of the Baltimore suburbs, most of them are housing developments, apartment complexes, trailer parks or similar. Some, however, do correspond to things that people would more readily describe as towns or suburbs. (Interestingly, none of Baltimore's neighborhoods shoed up in the GNIS import. All of the GNIS place=* nodes stop at the city line.) For the most part, I retag these nodes as landuse=residential unless I am reasonably certain they correspond to a larger place designation, in which case I give them an appropriate place= value. I have something of an advantage based on my location, because nowhere in the immediate Baltimore metropolitan region is there a place that would qualify as a hamlet (because the suburbs are all wide-ranging enough to be place=village or, in some cases, place=town). Note that I usually leave the nodes tagged landuse=residential, unless I'm in the mood for figuring out subdividion boundaries based on subdivision plats. I know that the landuse= tags make more sense on areas than on nodes, but it seems more correct to me than leaving the node tagged place=hamlet. I'm wondering what other people's experience with the hamlets are. Are they useful where you live? Are they nonsense (as they have been in NYC and DC)? I don't think they're nonsense. I think most of them in my area don't qualify for place= tagging, but most of them do correspond to *something* that actually exists. (Not all; if I can't match a node to a place name or subdivision, I'll just delete it, but that's not tremendously common in my experience..) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Hamlets!
* Elliott Plack elliott.pl...@gmail.com [2013-06-21 21:01 -0400]: In the city of Baltimore, we have over 250 well defined neighborhoods, yet their boundaries are defined by a planning dept., not the people per se. Most of the neighborhoods have nodes place=suburb, but it probably should be place=neighborhood. I put those there and at the time place=suburb seemed the best tag to use; place=neighborhood wasn't yet in common use. Based on my understanding of current usage of the tags, most should probably be place=neighborhood, but the larger or more prominent neighborhoods (like Hampden or Fells Point) should get place=suburb, in a vein similar to the distinctions between place=town/village/hamlet. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- #define NULL 0 /* silly thing is, we don't even use this */ -- perl.c, perl source code --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* James Mast rickmastfa...@hotmail.com [2013-06-22 07:22 -0400]: I do hope that the render will avoid using the Super relations. My rendering doesn't use super relations (mostly[0]), because it doesn't need to; the per-state relations contain all of the tags needed for it to get the right shields. the segment of I-26 between I-240 and Exit #9 is still considered to be a Future Interstate and it is posted as such with FUTURE tabs above all I-26 shields on that segment (and missing the word Interstate in the shields itself. Would it be worthwhile to declare a separate network for these (US:I:Future seems natural) and give them their own relations? If there are signs on the ground, I could see about putting images in my rendering for them. [0] At lower zoom levels the rendering uses the osm2pgsql route relation geometries for overview rendering of two-digit Interstate shields, which might end up using super relations, if osm2pgsql generates geometries from them, but that's a fairly minor part of the rendering and only applies from zoom 7 to zoom 9. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- kceee^ I hate users knghtbrd you sound like a sysadmin already! -- seen on #debian --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* Clay Smalley claysmal...@gmail.com [2013-06-20 09:26 -0700]: Also, even if it were the case that they were the same network, it makes sense to keep them separate because that is how the shield renderer determines which shield to put on the road. My shield renderer is pretty flexible. I can assign shields on a ref-by-ref basis, if need be (though it means that networks' shields require more maintenance in the long run).[0] As long as the solution has local consensus I'll find a way to work with it.[1] [0] See, for example, Georgia route 515, which gets a blue sign because it's part of an Appalachian Highway Development System corridor: http://elrond.aperiodic.net/shields/?zoom=12lat=34.66561lon=-84.48668layers=B [1] Or throw up my hands and say, I don't know how to handle that, but that shouldn't impede consensus. There are still a bunch of things I don't have a good way to handle yet, like the way Tennessee does primary and secondary state highways, or the way Maryland signs Business US Highways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* Ian Dees ian.d...@gmail.com [2013-06-18 08:07 -0500]: Because no one's stepped up to do it! Okay, I should probably put my toes in here. I can spend this weekend cleaning up my code (for http://elrond.aperiodic.net/shields/ ) and maybe try to get it running on the US server, if there's interest/approval. Note that it requires PL/python, which is an untrusted PostgreSQL language, and takes some tweaking to get all of the pathnames set up properly. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* Jason Remillard remillard.ja...@gmail.com [2013-06-17 22:19 -0400]: If the way is part of relation that has a ref, and the way itself does not have a ref, then the relation ref should propagate to the way. Note that the conventions for ref tags are different for relations and ways. A way that is tagged ref=I 70 should be a member of a relation that is tagged network=US:I, ref=70. (And a relation tagged network=US:US:Business, ref=15, modifier=Business would correspond to a way tagged ref=US 15 Business.) This sort of adaptation might be a good candidate for the Lua transformations recently added to osm2pgsql, but I haven't had a chance to really look at those yet. (Also, of course, such ref projection would need to take concurrencies into account. Sigh.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] ref tags
* Martijn van Exel m...@rtijn.org [2013-06-18 10:40 -0600]: Perhaps we can get together on IRC sometime soon and see what would need to be done. I can't make tonight but tomorrow early evening (like, 6PM MDT) would work. Ian, Phil, Toby, are you around then? That's 8pm for me, which might work. Depending on other stuff I have going on that evening, I might not be available until 8:30 or so (EDT). (Wednesday's my only free evening this week, so if it doesn't work I won't be available until Saturday sometime.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundary level quirk in NYC
* John F. Eldredge j...@jfeldredge.com [2013-05-18 09:49 -0500]: You might want to take a look at how Virginia is mapped. Cities in Virginia are not considered to be subordinate to counties, even if surrounded on all sides by a county. From what I've seen of Virginia, it seems to be mapped the way Maryland has Baltimore City: independent cities are considered to be coequal to counties and are mapped with admin_level=6, the same as counties. NYC is a little different in that the five boroughs are counties that are subordinate to the city (which, I suspect, is why NYC is currently mapped as admin_level=5). -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The problem with using C++ ... is that there's already a strong tendency in the language to require you to know everything before you can do anything. -- Larry Wall --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports-us] Baltimore Building Outlines Import
* Elliott Plack elliott.pl...@gmail.com [2013-05-04 09:43 -0700]: Building type: you might be able to tell if its classified residential or commercial or whatever from the GIS data. Spatial queries should be able to tell that in combination with the landuse shapefiles ( http://wiki.openstreetmap.org/wiki/Baltimore,_Maryland/Landuse and https://data.baltimorecity.gov/Geographic/Land-use-Shape/feax-3ycj ), although my only experience with doing that sort of thing has been with PostGIS databases; I don't know if QGIS can do it on its own. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I must first reveal my personal bias in this discussion, since I worship at the First Church of PDF Really Sucks. -- Bruce Tog Tognazzini --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Baltimore Building Outlines Import
* Matthew Petroff openstreet...@mpetroff.net [2013-05-04 00:07 -0400]: My only qualm with the data is that some buildings have more nodes than they need, but I'm not sure what can be done about it besides manually reviewing and simplifying all 200k+ outlines. My opinion on imports is that if manual intervention is the only way to keep the data at the same quality level that OpenStreetMap should be offering, then manual processes need to be part of the import, because an import should not degrade the quality of data in OSM. (This is why I rejected an direct import of the city's landuse data. http://www.openstreetmap.org/user/asciiphil/diary/13891 ) When I briefly discussed the building footprint import with Elliott, I said that, were I doing it, my process would involve pulling the buildings into JOSM and using JOSM's todo plugin to look at each new building and make sure it looks okay and migrate any tags from existing OSM building data. That's a lot more work than just bulk processing the data and dumping it into OSM, but I think the hand-cared aspects of our data are some of the most important things about this project and imports should only complement that care. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- OOPS! You naughty creature! You didn't run Configure with sh! I will attempt to remedy the situation by running sh for you... -- Perl configure script --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Airport Tagging
* Rick Marshall rick.marsh...@verticalgeo.com [2013-04-23 12:37 -0500]: 1. How do you mark Precision Approach Path Indicator (PAPI), Visual Approach Slope Indicator (VASI), VOR, and other Navigational Aids at airports. As far as I know, there isn't a widespread way of tagging these things. I turned up this wiki page: http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dnavigationaid but using type= for the type of navigational aid is probably not the best approach (because it's too generic as a tag and because it's already in use for determining relation types). I would probably do one of two things: 1. tag a VOR, for example, as aeroway=navigationaid, navigationaid:type=vor and add something to the aeroway=navigationaid wiki page about using navigationaid:type= instead of just type=. 2. Join the tagging@ list, suggest the above as a general tagging scheme and see what, if anything, comes out of the resulting discussion. You will need a fair bit of patience to go this route and it's a lot easier if you have been working with OSM data (contributing, consuming, or both) for a while first. When I tag my edits as aeroway=vasi or aeroway=papi they don't show up on the map. Is there a better way to tag the edits? Not at the moment. The main map rendering attempts to show a large subset of the various things in the OpenStreetMap database, but it typically doesn't go very deeply into specialized subsets of the data. There are other renderings that are more narrowly focused, like OpenSnowMap for ski resorts and winter sports or ITO Map's railways view. Things like these navigational aids would probably only be rendered by a specialized air traffic infrastructure map rendering, but I'm not aware of any such renderings that actually exist at the moment. (ITO Map has an airport details map at http://www.itoworld.com/map/163 , but it's pretty rudimentary.) 2. Who decides the geographical limits of an aerodrome? Normally, it should be the land specifically (and, usually, legally) set aside for it. This approach tends to work best for larger and dedicated-use airports. For smaller facilities where the land is shared-use (e.g. a farm that has an airstrip on it), either you do your best to outline only the land that is exclusively for air traffic or you just put a node roughly in the middle of the area with the aerodrome tags on it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
* Jason Remillard remillard.ja...@gmail.com [2012-12-28 16:16 -0500]: So the question is, what should the exact criteria be for including an open space parcel in OSM. Consider some of the various types of property. I've used parcel data as a layer in JOSM to trace from. It lets me be a little more accourate about some area boundaries than I could from just aerial imagery (and walking a GPS along, say, the border between a golf course and a residential area with private houses is a little out of the question). I'd be resistant to the idea of bulk import (pretty much anything beyond pulling individually-checked polygons into OSM) because I've seen a lot of places where a naive import of the parcel data available would have made for wrong or at least weird OSM data. I've seen a number of places where a single entity acquired its land over time, so the parcel records show multiple parcels that should be a single OSM entity. Similarly, I've seen a lot of places where a public road cuts through a single entity's land (golf courses especially, but also parks and residential areas). I feel it's more correct to make a single polygon that crosses the road, but parcel data would usually have the road splitting the area. I've also seen a few places where parcels were too broad, where a single parcel needs to be divided into several different OSM landuses. This is just my experience with the handful of counties in Maryland that have parcel data available under an OSM-friendly license. Maybe other jurisdictions have data that would provide a more one-to-one correspondence with OSm features. Even in those cases, an importer would need to make sure that the import fits topologically into OSM, interacting properly with existing data. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing shorelines
* Eric H. Christensen e...@christensenplace.us [2012-12-13 21:54 -0500]: On Thu, Dec 13, 2012 at 02:23:52PM -0500, Phil! Gold wrote: If you use JOSM, the ContourMerge plugin is very helpful here. Thanks for the advice. I've tried that technique and it seems to have done what I wanted but I'm withholding judgment until I actually see the results on the website. That might take a while. The data used to render coastlines is generated irregularly on approximately a monthly basis. You can take a look at an area a little ways north where I've done the same thing: http://osm.org/go/ZZfHNr1i . I've not been very impressed by the TIGER roadway data in my little town Yeah. The TIGER data for Anne Arundel County was really horrid at the time of the import. I've cleaned up a bunch of it in the northwest corner of the county (areas near BWI, Fort Meade, and Laurel), but there's a lot left to do. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing shorelines
* Jeff Meyer j...@gwhat.org [2012-12-13 12:58 -0800]: On Thu, Dec 13, 2012 at 11:23 AM, Phil! Gold phi...@pobox.com wrote: I use tilestache to go between JOSM's tile underlays and the ArcGIS REST interface). Do you have a pointer to any docs of how to do this? It's pretty simple. You use tilestache's URL template provider to proxy requests to the REST server. It works as long as the server supports the web mercator projection, which might be under any of the SRIDs 900913, 102113, 102100, 3785, or 3857. (The last is the current official code from EPSG.) Here's what I use for Anne Arundel County's orthoimagery: { layers: { AAOrtho2010: { provider: { name: url template, template: http://gis-world.aacounty.org/ArcGIS/rest/services/Ortho2010/MapServer/export?f=imagebboxSR=102113bbox=$xmin,$ymin,$xmax,$ymaxsize=$width,$heightformat=png24; }, preview: { lat: 38.974, lon: -76.595, zoom: 10 } } } } For their vector-based data, I add `transparent=true` so I can overlay it on aerial imagery: AABasemap: { provider: { name: url template, template: http://gis-world.aacounty.org/ArcGIS/rest/services/Basemap/MapServer/export?f=imagebboxSR=102113imageSR=102113transparent=truebbox=$xmin,$ymin,$xmax,$ymaxsize=$width,$heightformat=png; }, } ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Dual Carriageway?
* Jim McAndrew j...@loc8.us [2012-11-29 12:18 -0700]: From looking around on OSM, it doesn't seem like people are marking roads with a garden in the middle of the road as a dual carriageway, maybe they should be? For short islands in the middle of a road (like the links you gave), I usually don't map as a dual carriageway unless it makes a difference to routing (i.e. there's a road that only connects to one side of the island). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER expansion bot
* Serge Wroclawski emac...@gmail.com [2012-11-27 11:33 -0500]: On Tue, Nov 27, 2012 at 11:07 AM, Brian May b...@mapwise.com wrote: Another clarification for this use case: A user changes the original highway name tag from Main St SW to SW Main Street, but did not alter the tiger tags. I haven't seen any examples of this that seemed to expand incorrectly in my surveys of results. Are you able to point me to actual examples of this in the OSM US dataset? How would your bot handle this way? http://www.openstreetmap.org/browse/way/5321758 As one might expect, the name was corrected by a local who knows his street name but not necessarily all the tiger: tags. IMHO, nothing of this sort should be touched by a bot. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
* Steven Johnson sejohns...@gmail.com [2012-11-17 18:45 -0500]: http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates From my perspective, addr:street_prefix and addr:street_type don't seem that useful, since I don't see how they add information that's useful to data consumers and they require extra work from data contributers. If I understand things, the proposal would take a way tagged with name=Old Frederick Road and add addr:street_prefix=Old, addr:street_type=Road. What benefit is there to that? (Put differently, what motivation can you give to convince mappers that it's worth their time to add those tags on every road whose name they modify?) It's also worth considering how a tagging scheme can be broken. It's not uncommon for contributors to edit one tag and fail to notice related tags on the same object. How would you suggest handling, say, name=Wentworh Avenue, addr:street_type=Road? I do think there's a use case for directional prefixes that are not strictly part of the road name, but are instead for addressing. Many parts of the US have roads with addresses of the form 10 North Something Street where the road signs emphasize Something Street and the North or South parts are less visible. (I've seen many roads in my area where the signs for such roads are not even consistent in terms of whather it's a prefix or suffix; adjacent signs might show both N Something St and Something St N.) In these cases, I think it would be beneficial to have tagging of the form name=Something Street, addr:direction=North so routers can tell people things like, Turn left on Something Street, which reflects the signage, but geocoders can figure out where addresses are likely to be even in the absence of complete address information. (This sort of usage would require proposing changes to address tagging, as well as road tagging.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US State Shield rendering - Modifiers
* Mike N nice...@att.net [2012-11-13 09:38 -0500]: WOOT! We may have hooked a new US mapper because of the shield rendering on the test shield development server! Awesome! That leads to a related question - what is the best way to tag for modified state routes. For example in South Carolina: State route 49 - US:SC , ref = 49(That is clear) State Route 49 Bypass - US:SC:Bypass , ref = 49 , modifier = Bypass State Route 49 Truck - US:SC:Truck , ref = 49 , modifier = Truck State Route 49 Business - US:SC:Business , ref = 49 , modifier = Business This matches the on-list consensus on the topic and is what the shield rendering currently understands. State Route 49 Truck Bypass - US:SC:Truck:Bypass , ref = 49 , modifier = Bypass:Truck (in any order) This would also match the list consensus. In the absence of any compelling reason not to, I've set up the rendering to accept modifiers in any order, so it would treat US:SC:Truck:Bypass and US:SC:Bypass:Truck identically. Personally, I'd probably tag modifier=Bypass;Truck, with a semicolon, to match multi-value usage in other tags. What do we need to do to enable shields for this? Well, someone could put together the necessary sequence files and template images, if needed, and send me either a merge proposal or a patch from the code at https://launchpad.net/osm-shields. Alternately, I can set them up if you can get me some images of what the bannered shield signs look like and a list of bannered routes in South Carolina. (I can manage with just the reference images if you're okay waiting until I notice the unmatched routes in the OSM data.) I've gotten a bit behind in code maintenance--the most recent reason being a new job that's absorbing more of my time than usual--but I hope to get back to the shield rendering soon. (Take heart, Minh Nguyễn, I'll get the Ohio county routes in yet.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
* Paul Norman penor...@mac.com [2012-10-28 20:51 -0700]: A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. I do a lot of tracing streams from aerial imagery with the NHD as an overlay for names and pointers as to the flow locations. (I prefer tracing to importing because I can achieve much better accuracy than the NHD, plus I ensure that the waterways interact properly with roads by adding bridges and tunnels as necessary.) Based on my experience with the NHD, I think an import should probably include FCode 46006 streams; I've seen quite a few decent-sized streams without names that I feel definitely enhance the map by their presence. I probably wouldn't have objections to removing FCode 46003 streams, but be aware that the NHD is the product of a lot of different people entering data over a span of many years (sound familiar?) and the threshold between 46006 and 46003 can vary significantly from area to area, presumably depending on the judgement of the pople entering the data. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Miskatonic University Alumni Association Go pods! --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another random road reclassification
* Toby Murray toby.mur...@gmail.com [2012-08-14 23:26 -0500]: http://www.openstreetmap.org/?lat=39.117lon=-94.8924zoom=14layers=M I know there is some disagreement about road classification, especially when it comes to trunk but I'm pretty sure most people would agree that this is incorrect. Thoughts? I agree with your assessment. In my opinion, road classifications are most useful when applied over significant stretches of road. I don't think a rural freeway that has someone's driveway on it needs to be dropped from motorway to trunk around that driveway, and I don't think a divided expressway with mostly at-grade intersections but a few interchanges should be upgraded from trunk to motorway around the interchanges. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
* Alan Mintz alan_mintz+...@earthlink.net [2012-07-29 18:54 -0700]: [1] When combining ways in JOSM (at least), values for tiger:* tags are combined with : (colon) as a delimiter, instead of ; (semi-colon). Why, and should this be changed? I believe this behavior was intended to make tiger:tlid merging work a little better. As I understand it, the TIGER data originally imported was structured so that a single road was composed of many segments connected end-to-end. For the import, all segments with the same data values were concatenated into a single way and the IDs of each constituent segment were concatenated, separated by colons, and stored in the tiger:tlid tag. Thus, when combining two TIGER ways, using a colon to join their tiger:tlid tags would give a roughly correct reflection of the mapping between TIGER data and OSM data. I don't know why the decision was made to apply that to all tiger: namespace tags rather than just the tiger:tlid tag. Obviously, this doesn't help with way splits; the tiger:tlid value gets copied to each half, even though the original segments are now divided across the two ways. On top of that, TIGER doesn't use the segment structuring anymore; their data is more like OSM now, and each road gets a feature ID that's unrelated to the old TLIDs (though there might be a table somewhere providing a correlation between the two systems). Given all that[0], it seems reasonable to drop tiger:tlid on edits like the created_by tag. [0] Plus my personal experience that I periodically have to delete tiger:tlid tags after merging ways because the resulting tag value exceeds OSM's length limit. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
* Mike N nice...@att.net [2012-07-19 17:01 -0400]: FYI in South Carolina, I'm volunteering to clean up the northwestern part of the state because I have some local knowledge. Cool. I've just finished looking over I-20 and repairing all the roads that were split to make bridges over it. I mostly left them classified highway=residential; I'd prefer to leave road classification to someone more familiar with the area. I plan to start cleaning up I-95 next; it looks like it's got big chunks missing, among other problems. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- For every meme, there is a Cafe Press shop, where you can buy t-shirts, mugs, and thongs. -- Xeni Jardin --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
* Toby Murray toby.mur...@gmail.com [2012-07-19 00:42 -0500]: Any other common problems that people have seen? Probably the most common thing I've seen is what TIGER road splits look like: one way (usually leading up to a bridge), followed by a string of unconnected nodes. Fixing these is pretty easy: click along the unconnected nodes to draw a way connecting them (and recreate the bridge or whatever, of course). Having Bing or other imagery underneath helps you know when to stop or keep going. I've also seen a bunch of motorway_links without oneway tags, so that's definitely something to keep in mind. Are there other important, non-obvious tags that it would be good to specifically be checking for? -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Science is built up of facts, as a house is with stones. But a collection of facts is no more a science than a heap of stones is a house. -- Jules Henri Poincare --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
* Martijn van Exel m...@rtijn.org [2012-07-19 14:22 -0600]: On Wed, Jul 18, 2012 at 11:42 PM, Toby Murray toby.mur...@gmail.com wrote: Any other common problems that people have seen? Another thing I find is a lot of leftover stray nodes without any tags. I select them in JOSM with type:node tags:0 -child and delete them in one fell swoop. Eeek! Be very careful with this! The unconnected, untagged nodes were left deliberately to facilitate recreation of roads, particularly the case where a decliner split a TIGER way but did not change its geometry. I've been making use of these nodes in South Carolina to reconstruct the roads there. ___ 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 techl...@techlady.com [2012-07-19 15:58 -0700]: That's great, but will it overwrite work that we've already done? Presumably not. Potlatch loads shapefiles into a separate layer and requires mappers to manually pull the data into OSM. Also, is this something that works only in JOSM, in which case many of us couldn't use it? No. For one thing, Richard is the main developer of Potlatch and doesn't do anything with JOSM. For another thing, he mentioned reworking the P2 source code; P2 refers to Potlatch 2. Also, I still don't understand why all the TIGER data was deleted on ways that were partially deleted. Because of OpenStreetMap's data model. When you split a way, what your editor does is upload a changed version of the original that only contains half the original nodes and then upload a new way with the same tags as the old one that contains the other half of the nodes. To subsequent database queries, the second way appears as though you created it and there's no direct link back to the way that originally contained the nodes. On top of that, there was a deliberate decision made (as I understand things) not to undo deletions, which includes the removal of nodes from a way. Had the bot done that, there would be many places where the bot would create multiple, overlapping, tangled ways. Since either approach would have left significant messes for mappers to clean up, there wasn't really a good way forward. The people working on the redaction bot felt that not undeleting would be the better of two bad options. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- i am not interested in a penis for aesthetic purposes. -- isabelle whitman --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Redaction bot is heading our way!
* Kai Krueger kakrue...@gmail.com [2012-07-18 18:26 -0700]: Chris Lawrence-2 wrote I've fixed up I-20 between the Columbia River and US 21 I also started fixing the I-20 at the intersection to I-77 I also started working on I-20, from the Georgia border. (I had qualms about just going with the first one Wikipedia listed on their numbered routes in South Carolina page...) I spent a bunch of time reconstructing the roads that cross it, though; for a lot of them, all the decliner/non-responder did was split them to make bridges, which ends with the road still on one side of the Interstate and a line of nodes on the other side, so it's not too hard to recreate the roads. The question is, is it better to fix up a small bit thoroughly, or try and get as much of the interstate at least vaguely right as soon as possible, and leave the rest to a second pass? IMHO, interstate connectivity is most important, but I figure reconnecting roads that were split to cross the interstate will get decent other chunks of the road network functional, too. Unfortunately, I think I also ran into an editing conflict with you, as when I wanted to upload my changes, potlatch complained about version miss match on the I-20 relation. I hit a conflict with someone, too, but I think I correctly integrated both sets of changes. It helped that the other person had been working on a different area of the relation, and neither of us had drastically reordered the relation members. So another question is, what is the best way to coordinate the general fixing of the interstate system to try and minimize editing conflicts? I'm not sure. Maybe listing the Interstates (and perhaps US Highways) on the wiki and letting people claim them one by one? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Scenic/Historic byways
* Toby Murray toby.mur...@gmail.com [2012-07-08 14:20 -0500]: Closer to home I have also seen a Scenic Byway sign. This seems to be an official designation by the US DOT as discussed here: http://en.wikipedia.org/wiki/National_Scenic_Byway I've done a bit of reading about these, mostly as they pertain to Maryland. It appears that most of those are also state-designated scenic byways, and a state will probably have other scenic byways that are not nationally recognized. So how do we map these? In Maryland, the state has a brochure showing more or less where the byways are, and they're not entirely consistently signed[0]. I've put one into OpenStreetMap[1] and tagged it much as you did the Western Vistas Historic Byway, but I used a network of US:MD for lack of a better option. (US:MD:Scenic Byway might make sense, too.) I think the state-based scenic byways should have state-specific network tags. There are a few that are not state scenic byways, like Skyline Drive in Virginia. I'm not sure what would be a good network for those. I think the best way to handle National Scenic Byways and All American Roads is just to add national_scenic_byway=yes and all_american_road=yes tags (sorry) to the route relations as appropriate. That probably doesn't address your Historic Byway, but I haven't read anything about those. [0] I've been on three of Maryland's scenic byways since I started paying attention to them, and have only followed one for its entire length. That one (the Horses and Hounds Scenic Byway) only has signs right before the byway turns onto other roads and those signs do not indicate which way the byway turns. The Catoctin Mountin Scenic Byway (also a National Scenic Byway) more or less runs along the entire length of US 15 in Maryland and has signs dotted along the side of the road. The Star Spangled Banner Scenic Byway runs along most of the length of the Baltimore-Washington Parkway, but I've only seen one sign on the B-W Parkway--on the northbound side, just before MD 175--and it doesn't have the name of the scenic byway on it. [1] http://www.openstreetmap.org/browse/relation/2188238 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rails with trails
* Nathan Edgars II nerou...@gmail.com [2012-06-27 12:59 -0400]: But another popular kind of rail trail, a rail with trail, cannot be found in this manner. [snip] Does anyone have any ideas for tagging? The simplest would be something like rail_with_trail=yes or maybe railway=adjacent. Either of those would work. Between those two, I'm inclined toward railway=adjacent so the search would be something like highway=(path|footway|cycleway) and railway=(abandoned|adjacent). Another possibility would be to use rail_trail=yes, which would apply to any rail trail. It would be implied by a non-motor-vehicle highway= tag and railway=abandoned, but could always be specified to be unambiguous. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] holes in Columbus OH?
* Peter Dobratz pe...@dobratz.us [2012-06-12 00:45 -0400]: There seem to be a lot of holes in the multipolygon relation, and it seems strange to me that there are so many places within the city that are not part of the city. Is anyone more familiar with this area that give an explanation for this? It's not uncommon for cities to have unusual shapes, including holes like that, as they can have annexed land around but not within a given area. In the specific case of Columbus, the holes look legitimate. I looked up Columbus on Wikipedia and found this map of the city: https://en.wikipedia.org/wiki/File:Columbus_Overview_Map-150dpi.png The white part is the city proper and the colored parts are independent suburbs, which seems to match (to a first approximation) the OSM data. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
* William Morris wboyk...@geosprocket.com [2012-05-31 21:25 -0400]: Trying this again, after a hiatus, here is a sample of a few hundred buildings from a UVM-SAL land use classification. In this case it's for an area just west of D.C. in Montgomery County, MD. I offer it for your consideration before I pull the import trigger: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm I share the reservations already expressed about the nodiness and blobbiness of the buildings. Here's one set of buildings, shown against Maryland's aerial imagery: http://static.aperiodic.net/tmp/md-mo-bldgs.png I'm not convinced that a county full of blobs like that will look good on the map and, thus, whether it would be an improvement over letting mappers put the buildings in as they get to them. I'm more comfortable with things like the building import done a few months ago around Salisbury in eastern Maryland where the data is much cleaner and, I think, better serves as a basis for further improvements from local mappers. I think that this level of accuracy, while reasonably-well-suited to landcover data, isn't really good enough for buildings. I'm also over in Baltimore County, so I'd like to hear what other regional mappers think. Some steps I've taken to make it community-friendly include: - Removed all buildings that intersected existing OSM features Definitely an important step. Thank you. - Removed all buildings smaller than 5000 square meters in area, since those residential structures weren't being very well-detected anyway There's not really a good cutoff for this, though. I saw a couple of housing developments with blocks of townhouses where random sets of townhouses were missing. Presumably the missing ones fell below your threshold while most of the blocks didn't. It might be useful to go much higher and target just the largest buildings (which would also be the more significant landmarks). Over all of your data, what does the distribution of building areas look like? -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Go climb a gravity well! --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
* Kate Chapman k...@maploser.com [2012-05-10 14:01 -0400]: I think if we were too look at what is on the sign I bet it is U.S.S. MLK though often fully spells out the name on the sign. I would think in these cases it should be what is on the sign. Since it isn't an abbreviation of the road type, but the actual street name. I agree. I've made similar decisions about stuff in my area. The right of way of the old Washington, Baltimore and Annapolis Railroad has been repurposed in various places. One part is a road signed as WBA Road, which I've opted to tag as name=WBA Road. Another part is a hike/bike trail often referred to as the WBA Trail, but officially called the Washington, Baltimore and Annapolis Trail, so I've tagged it as name=Washington, Baltimore and Annapolis Trail. (Coincidentally, as I looked at the map to check my tagging, I saw that another part of the WBA right of way is a Martin Luther King Jr Highway.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- (format t ~@? (format t \~~@?\ ~:*~S)) --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
agree with this. From the point of view of using the data to make maps, I like this approach better than a separate modifier tag. It was based on that thread and the previous one (Use of ref-tag on state highways) that I felt there was a reasonable consensus in favor of network-classification-per-banner, based on the fact that only one person objected to it. Apr 02, 2012: Highway Shield Rendering gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5612357.html Hey, that's this thread! Chris Lawrence (the person who originally wrote the bit on the wiki about using the modifier tag) appears to also support network-classification-per-banner: After more thought, in the general case, deprecating modifier and just using network to denote variations using the established : separator convention is probably sanest. Paul Johnson feels as NE2 does that this means that the network tag no longer represents a distinct network (and that's a bad thing): Well, that kind of breaks the whole network concept then, and the key should probably be renamed to fit the expected data... Craig Hinners, although comfortable using the network tag to represent distinct network subsets separately from their mainline portions, doesn't like using it to mark geographically-distinct signage for what's otherwise the same network subset: Phil! Gold phi...@pobox.com: It seems to me that network=US:US:Business:MD is the logical extension of a scheme that has US:US and US:US:Business. My initial reaction is that this goes too far in mixing geographic, classification, and rendering concepts, which has a bad smell Michal Migurski says he's used the modifier tag as a data consumer: For what it's worth, as a renderer I preferred the modifier tag when doing the Terrain shields: http://maps.stamen.com/terrain/#13/34.0510/-118.2146 Modifiers in the ref tag would be a close second; those typically need a lot of scrubbing and normalization an yway. In the network tag would be the biggest hassle of all. I mostly support the network-classification-per-banner (though from a coding perspective, the alternatives would be just as much work for me to handle): I think this highlights a reason to use network subsets in the network tag: because it's a simpler rule to apply than deciding whether a variant route is different enough to deserve its own network value. If you count out all the emails on the subject, there are probably more emails opposing the network-classification-per-banner approach, but if you count the people expressing opinions on the matter, network-classification-per-banner has a strong majority. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I smell a wumpus. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-12 15:52 -0400]: On 4/12/2012 2:59 PM, Phil! Gold wrote: * Minh Nguyenm...@1ec5.org [2012-04-12 10:06 -0700]: There's an ALT I-75 that needs its own sequence file I wouldn't necessarily oppose a separate network tag in this case, since it's clearly not part of the Interstate Highway System. (The same would apply to business Interstates.) * Nathan Edgars II nerou...@gmail.com [2012-04-12 16:03 -0400]: Also I-270 Spur in Maryland, which *is* part of the Interstate Highway System and thus belongs in network=US:I First off, I still feel that there was a consensus last year on using the network tag for distinct network subsets as well as for mainline roads and you, despite being the only dissenter, continue to argue against something the rest of community more or less settled on. Secondly, I think this highlights a reason to use network subsets in the network tag: because it's a simpler rule to apply than deciding whether a variant route is different enough to deserve its own network value. You seem to have a clear idea about what constitutes a network from your perspective--Interstate 75 Alternate and Downtown Interstates do, but Interstate 270 Spur doesn't. I think there's a lot of grey area where people with different perspectives would disagree[0], especially mappers who just want to represent what they see on the signs where they live without arguing the minutiae of which road network a route is really a member of. In short, you seem to want to have the final say about what is or isn't a real network, but OpenStreetMap is a community effort and not only does the network tag can have distinct values for network subsets scheme appear to have broader community support, but it also seems to me to be the most generally applicable by people who in all likelihood will have different opinions about what *really* constitutes a distinct road network. [0] I feel, for instance, that I could make a convincing argument either way as to whether Texas's loop roads should count as their own network or should be part of the state's main network. Likewise for routes signed as US 1, US 1A, and US 1 Alternate. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- How do RPG characters manage to carry so much? Very deep pockets. -- MenTaLguY --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-11 17:33 -0700]: On Apr 11, 2012 11:48 AM, Phil! Gold phi...@pobox.com wrote: From what I've read, all US highways in California should get similar treatment, in that they're signed with different shields than the standard ones. Are there other regional sign variants for broader road networks in the US (or elsewhere)? Some US highways (segments of US 75A for sure) and many state highways feature generic white circle state route signage, though it's not clear to me if this was deliberate or a case of sign shop error, or older signs not yet replaced, respectively. I think I'd prefer to ignore unusual or one-off sign variations like those. Let me put it this way: Are there any other places where a local organization responsible for making and placing signs along a route has an official policy of placing signs that differ significantly in appearance from the signs used along the rest of the network? US Business routes in Maryland meet these criteria. Where else is this true? -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- main(a){printf(a=main(a){printf(a=%c%s%c,34,a,34);},34,a,34);} --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-12 00:09 -0700]: Thanks for your attention to detail! You're welcome. :) By the way, four-digit circle shields appear to have broken over the last day or two. Indeed they were. It should be fixed now, pending a rerender. (A few days ago, I changed the shield generating mechanism from pregenerating every shield and every known cluster (in every possible orientation) and saving them in directories--to only pregenerating every individual shield (which is still almost 45,000 images), storing them in the database, and letting the database generate the clusters on demand. With the old system, we'd been cheating a little with the circle- and lozenge-style shields by generating two sets of images (one with circles for all numbers from 1 to , and one with circles for 1 to 99 and lozenges for 100 to ) and then symlinking states to those as appropriate. With the new setup, we have to generate all the shields for each state individually and I just didn't go high enough for Kentucky. I've now generated shields for Kentucky up to 3999, which should cover everything I see in the database. Wikipedia lists 9006 and 9008, but it looks like those are unsigned reference numbers for some of the parkways.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- You know you're really somebody in the software world when Richard Stallman complains about you having a gratuitous patent -- Source unknown --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* James Mast rickmastfa...@hotmail.com [2012-04-12 09:40 -0400]: You need to create shields up to at least in the 6000 range for Kentucky. The reason I'm saying this is that the have a 6000 series for small service roads. [snip] So, on the safe side for the KY routes, I would create shields up to at least 6299 so that when people get around to properly tagging the 6000 series, they will be rendered when necessary. Are there any roads in the 4000s or 5000s? If not, I can skip those and just do the range from 6000 to 6299. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I think... I think it's in my basement... Let me go upstairs and check. -- Escher --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-12 10:06 -0700]: There's an ALT I-75 that needs its own sequence file I had no idea there were alternate Interstates. I added it under network=US:I:Alternate, ref=75. (Right now, it's rendering as regular I-75.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Hydrogen is a colorless, odorless gas which, given enough time, turns into people. -- Henry Hiebert --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
* Craig Hinners cr...@hinnerspace.com [2012-04-08 07:07 -0700]: Phil! Gold phi...@pobox.com: It seems to me that network=US:US:Business:MD is the logical extension of a scheme that has US:US and US:US:Business. My initial reaction is that this goes too far in mixing geographic, classification, and rendering concepts, which has a bad smell I plan on experimenting with basing some rendering decisions on the is_in tag, which should work for Maryland's US business routes (assuming it works at all; is_in values aren't really standardized). From what I've read, all US highways in California should get similar treatment, in that they're signed with different shields than the standard ones. Are there other regional sign variants for broader road networks in the US (or elsewhere)? -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Research is to see what everybody else has seen, and to think what nobody else has thought. -- Albert Szent-Gyoergi --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Phil! Gold phi...@pobox.com [2012-04-03 17:27 -0400]: Okay. If there aren't any strenuous objections from other Virginians on the list, I'll go with US:VA:Secondary for the secondary routes and won't render them if they're tagged US:VA. I've made this change. It'll take a little while for everything to rerender. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Who do you think you are, Zaphod Beebelbrox? Count the heads. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]: More requests: in addition to its circular-shield state highway system, Kentucky also has an ad-hoc parkway network. At least some of them are tagged `network=US:KY:Parkway` with a shield URL in `symbol`. Since I've now got shields rendering larger at higher zoom levels, I made some shields for the Kentucky Parkways. They are indeed pretty unreadable until you get to about z17, but at that point you can mostly make out what they are (or you can also just read the name on the road...). At least there's something on the motorways so they don't just look naked. We're putting the shield images in the public domain (well, we're putting them under a CC0 waiver, which amounts to the same thing semantically), so I don't think the Kentucky Unbridled image would be compatible with that. I just went with an italic font. (It's not like you can tell at these resolutions, anyway.) One way to simplify them would be to use the routes' two-letter abbreviations. NE2 suggested this for New York's parkways, too. I want to see how the current shields are received now that you can zoom in and see more detail on them, but using the routes' initials is certainly a possibility if no one likes their current incarnation. Adding to the mess, the AA Highway is a special case that I *think* belongs in `network=US:KY` as `ref=AA`. I've added that, too. The network=US:KY, ref=AA relation does not appear to include all of the ways with the name AA Highway (it looks like the relation ends somewhere around KY 2828). -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The greatest obstacle to discovery is not ignorance, but the illusion of knowledge. -- Daniel Boorstin --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-09 17:40 -0400]: Is there a reason there are no shields or fallback ovals here on Nocatee Parkway? http://elrond.aperiodic.net/shields/?zoom=15lat=30.12344lon=-81.39063layers=B0 The way is tagged ref=CR 210 and the relation is network=US:FL:CR:St. Johns ref=210. The short answer is that it appears to be a rendering bug. The happy response is that I just finished a reworking of the shield image generation process[0] which appears to have fixed that bug as a side effect. County shield support is still pending[1], so it just gets the fallback shields for now. [0] The main benefit is that shield clusters are now generated on demand, rather than in a separate batch process. This should help keep the rendered map more up to date. [1] Including New Jersey county routes. I took them out because they didn't really fit into the code reworking I did. They'll return when I get the general-purpose county shield rendering working. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Your pet monster should be kept in a secure cage from which it cannot escape and into which you cannot accidentally stumble. -- Evil Overlord's Handbook, entry 28 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-04 22:26 -0400]: On 4/4/2012 10:23 PM, Nathan Edgars II wrote: There seems to be a problem here with US 17-92: http://elrond.aperiodic.net/shields/?zoom=12lat=28.96029lon=-81.31906layers=B0 Change over to sign style and a bunch of shields appear. Er - upon rerendering, they don't appear in sign style anymore. That definitely says there's a problem now. I appear to have inadvertantly broken the rendering of shield clusters with one of my code changes last night. (One of the deawbacks of having the only public version of this also being my development environment.) It's fixed now[0], and I've scheduled that area for rerendering. I'll see if I can tell which other areas were rendered during the bad window and get them rerendered. [0] It's fixed with the cutout shields. Because of some changes I'm working on, I don't have the source images to fix the sign style at the moment, so it'll take me a little while to regenerate them. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Only one human captain has ever survived battle with a Minbari fleet. He is behind me. You are in front of me. If you value your lives, be somewhere else. -- Delenn (Babylon 5, Severed Dreams) --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]: More requests: in addition to its circular-shield state highway system, Kentucky also has an ad-hoc parkway network. [1] At least some of them are tagged `network=US:KY:Parkway` with a shield URL in `symbol`. The Kentucky Parkways are on our TODO list. I put them off initially because not all of them have public domain SVGs on Wikipedia, so we'll have to find appropriate reference images and make our own. Unfortunately, Kentucky has made these highways' shield designs more and more intricate over the years, most recently for the state's Unbridled Spirit tourism campaign, to the point that they're more appropriate as entire guide signs than shields. I know you prefer to keep true to the official signage, but the various shields are simply illegible at the current size. So I see. The old signs looked different enough that if you knew them you'd probably be able to tell them apart even if you couldn't read the tiny text. The new ones look like they're too similar for that. New York's parkways have a similar problem with legibility. One of my plans for dealing with them is to use larger shield images at high zoom levels. Kentucky's parkways would probably benefit from this approach as well. Adding to the mess, the AA Highway is a special case that I *think* belongs in `network=US:KY` as `ref=AA`. It'd be nice to get that shield on the map, too. I've made a note of that in the TODO. It won't render until we make images for its and the other parkways' shields. Finally, I just added `network=US:OH` and `symbol` to the Ohio Turnpike, à la Pennsylvania. And there it is: http://elrond.aperiodic.net/shields/?zoom=13lat=40.92904lon=-80.56185layers=B0 (It wasn't rendering before because the cluster script hadn't created a cluster for it yet. I forced that through.) There's no shield for I-76 because it's tagged as ref=I 76. Also, the rendering doesn't use the symbol URL. It's not bad to tag it, of course, since it's potentially useful information, but it won't affect our rendering one way or another. Looks like the Indiana Toll Road has no relation yet. That's fine. We don't have a shield for it yet either. :) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- What can you tell me about Dracula? Dracula? Poncy bugger owes me £11, for one thing. -- Riley and Spike (Buffy the Vampire Slayer, Buffy vs. Dracula) --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-04 14:01 -0700]: OK, I'll bite. How is putting banners in the network tag preferential? why not something like... network=US:TX:FM modifier=Business network=US:US modifier=Business is_in=Maryland Each of the potential tagging schemes had drawbacks. One of the chief drawbacks of this one is that a naive data consumer that looks at the network and ref tags but not the modifier tag will get drastically incorrect results. (If it looks only at the network tag, then that's useful information on its own. If it looks only at the ref tag, it's not that useful, but it's also not likely to come to incorrect conclusions about the data.) For the record, the drawbacks of the other approaches are: * network=US:US, ref=50 Business Mingles base reference numbers and route modifiers together in a way that's difficult or at least annoying for data consumers to process. Addressing this problem was one reason for separating the network and ref tags on route relations in the first place. * network=US:US:Business, ref=50 Separates mainline routes from their alternates and variants, even though all of them are, outside of OSM, in the same road network. Complicates things for data consumers who care about the main network but not whether a route is a mainline or variant (not that there are any such consumers that I know of, but it would be a problem for them). -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Signal_11 I'm trying to grow sentient molds to karma whore on slashdot. -- seen on #kuro5hin --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Phil! Gold phi...@pobox.com [2012-04-05 08:14 -0400]: * Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]: Looks like the Indiana Toll Road has no relation yet. That's fine. We don't have a shield for it yet either. :) Ah. And that's because my visit to Wikipedia left me unsure what the current design for the Toll Road's shield was. Any pointers would be appreciated. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- joeyo msg nickserv identify m0rd0r joeyo doh! * SignOff joyeo: #kuro5hin (Killed (NickServ (GHOST command used by Dolgan))) -- seen on #kuro5hin --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Richard Weait rich...@weait.com [2012-04-04 01:09 -0400]: On Wed, Apr 4, 2012 at 12:33 AM, Phil! Gold phi...@pobox.com wrote: * Chris Lawrence lordsu...@gmail.com [2012-04-03 10:21 -0400]: http://elrond.aperiodic.net/shields/?zoom=14lat=37.13887lon=-80.34525layers=B0 http://elrond.aperiodic.net/shields/?zoom=14lat=37.19653lon=-80.22878layers=B0 Try those URLs again Wow. Vertical pairs. Looks nice, and switches back to horizontal as the line orientation changes. :-) I stayed up way too late last night. Try visiting those URLs again. (Once again, most of the map will rerender after you've looked at it so the way to see the changes in different areas is to look at them once then come back as much as a half hour later.) Other places that I know are rerendered include these: http://elrond.aperiodic.net/shields/?zoom=14lat=37.27562lon=-79.93635layers=B0 http://elrond.aperiodic.net/shields/?zoom=13lat=40.12983lon=-74.71446layers=B0 -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- ps axh -o%p | xargs perl -e '`kill -9 $ARGV[rand @ARGV]`' --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-04 10:41 -0400]: On 4/2/2012 11:35 AM, Phil! Gold wrote: For things like Florida's toll roads, we currently treat that as a separate network, so a route relation tagged as network=US:FL:Toll, ref=528 would get the toll shield. I've done this: http://www.openstreetmap.org/browse/changeset/11177509 The server's a bit overloaded at the moment, so already-rendered tiles might take a while to rerender and show the shields, but new renderings of not-yet-present tiles are given priority, so I was able to get some fresh tiles at zoom 15: http://elrond.aperiodic.net/shields/?zoom=15lat=28.4117lon=-80.82026layers=B0 -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- He won't be able to summon a demon THAT quick... -- Famous Last Words, #879 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Josh Doe j...@joshdoe.com [2012-04-04 08:55 -0400]: Is this something that could be used in a Carto stylesheet, or does it use special syntax only supported by XML? I'm not sure, because I don't really know Carto. Most of the magic comes from two places: first, there are PostgreSQL functions that take a way ID and return a string that gives the path to the shield for that way; second, there's the path expression syntax added to Mapnik2 that lets you use database fields in image filenames. If you can represent both of those in Carto, you don't need to touch an XML stylesheet. Just for reference, here's a relevant extract from the XML we're using: Style name=roads-text-ref Rule Filter[highway] = 'motorway' and [route_shield] lt;gt; ''/Filter maxscale_zoom13; minscale_zoom18; ShieldSymbolizer file=shields;/[route_shield].png minimum-distance=30 no-text=true placement=line spacing=640 fontset-name=book-fonts size=10 fill=whitenull/ShieldSymbolizer /Rule !-- ... -- /Style Layer name=roads-text-ref status=on srs=osm2pgsql_projection; StyleNameroads-text-ref/StyleName Datasource Parameter name=table (SELECT way, highway, aeroway, ref, char_length(ref) as length, CASE WHEN bridge IN ('yes','true','1') THEN 'yes'::text ELSE bridge END AS bridge, route_shield(osm_id) route_shield FROM prefix;_line WHERE (highway IS NOT NULL OR aeroway IS NOT NULL) AND ((ref IS NOT NULL AND char_length(ref) BETWEEN 1 AND 8) OR route_refs(osm_id) IS NOT NULL) ) AS roads /Parameter datasource-settings; /Datasource /Layer I know it's not really relevant to this thread, but since you have a separate stylesheet from the standard OSM one, maybe you could reduce the prominence of standard highway labels on residential/unclassified highways: http://elrond.aperiodic.net/shields/?zoom=15lat=38.78332lon=-77.30564layers=B0 https://trac.openstreetmap.org/ticket/4183 Ooof. I'm trying to limit the stylesheet changes to just what's needed to put our shields on properly, but I can probably tweak the font settings on those a little. They do kind of need it. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Like the ski resort full of girls hunting for husbands and husbands hunting for girls, the situation is not as symmetrical as it might seem. -- Alan MacKay --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Network tag Re: Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-04 11:54 -0400]: It seems that many people see the network tag as not representing a network but a shield design. Does this sound accurate? That matches my sense of what people have said about the tagging. I've been thinking of them in terms of subsets of a larger network, but since the subset is largely determined by how it's signed, it amounts to the same thing. * Craig Hinners cr...@hinnerspace.com [2012-04-04 09:14 -0700]: One of many examples: Maryland uses a unique green-on-white shield for US Business routes, but those roads still get tagged as network=US:US:Business, not network=US:US:Business:MD or somesuch. It seems to me that network=US:US:Business:MD is the logical extension of a scheme that has US:US and US:US:Business. I had actually planned on attaching Maryland's US Business shields to the US:US:Business:MD network once I made them, but I haven't gotten to those yet. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- vees my htaccess ban finger is twitching -- seen on #umbclinux --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-04 11:51 -0400]: (By the way, if it wasn't clear, you've done some good work here.) Thank you. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- There's a frood who really knows where his towel is. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* CrystalWalrein closed...@hotmail.com [2012-04-02 15:45 -0700]: For areas in New Jersey, when I look at this rendering, I get county shields for all 500-series roads, but no shields are shown for 600-series roads anywhere. The formatting for county route relations in New Jersey is 'network=US:NJ:[county name]' for all county routes that are not part of the statewide system (for which 'network=US:NJ:CR' is used). This is a known problem and more or less falls under we're not really doing county roads yet. We render the pentagon for routes with the network US:NJ:CR, but there's no rendering yet for US:NJ:county. That's partly because I haven't sorted through the counties to separate out the ones that don't use the blue pentagon, and partly because handling a lot of differently-named but having-very-similar-shields networks would be kind of a pain with our current setup, so I need to write some more code to help with that. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I think... I think it's in my basement... Let me go upstairs and check. -- Escher --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-03 02:19 -0700]: Displaying concurrent shields in bunches is certainly an improvement over all the maps that just pick one shield to display, and they look like reassurance sign assemblies to boot. But it's still strange to see shields hanging off either side of a north-south stretch of road. [1] How does this compare? http://elrond.aperiodic.net/shields/cincinnati.png I opted to string three shields out in a row because I think that fits into the rendering better; most text is horizontal, so there's less chance for conflicts, plus three-shield reassurance signs almost always have them in a single row. I could probably be convinced to do it differently if enough people prefer the two-row rendering. I'd prefer to see the shields strung out along the concurrency, with no spacing between each shield. That would be especially helpful where the concurrency's shields happen to appear near a junction. Google Maps does that, but they space the shields apart somewhat. This is something that would probably look nice, but is difficult (possibly impossible) to do in Mapnik. I'll see what I can do and how it looks on the map. Better yet, two routes of the same network could share a vertically stretched shield, like on printed maps. I'm resistant to this idea. Part of our goal for this rendering was to make the map look like what's actually on the road signs. With only a couple exceptions that I know of[0], concurrencies are always signed with separate sheilds for each route. Ohio's and Kentucky's shields look perfect. How about replacing the words INDIANA and ILLINOIS with slightly larger I N and I L for readability? [2] [2] http://elrond.aperiodic.net/shields/?zoom=15lat=38.68386lon=-87.53913layers=B0 Hm. Again, I'd prefer to match the reference signs as much as possible and leave it up to context to distinguish similar signs. (Maine and Massachusetts are close neighbors, for example, and have identical plain rectangular shields. And quite a few states use plain circular shields.) I did increase the size of the text on those two states. The 'L's in Illinois are a little more obvious now, though Indiana is still completely unreadable. I'll think about just putting the initials in (though it still might be a challenge to make it readable). [0] The US 1/US 9 concurrency in New Jersey is signed as US 1-9, and the MD 2/MD 4 concurrency in Maryland is signed as MD 2-4. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The Alchemist's Guild is opposite the Gambler's Guild. Usually. Sometimes it's above it, or below it, or falling in bits around it. -- _Men at Arms_, Terry Pratchett --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-02 14:34 -0400]: A total of *two* relations have network=US:US:Business, vs. 707 with network=US:US and modifier=Business. Yes, I know I had major influence in that, but that was months ago. There's also one US:OR:Business (which also has modifier=Business), one US:CA:BUSINESS, and one US:I:BUSINESS:SPUR (which surprised me; I wasn't expecting to see that in the database). Even though the last time this was discussed in detail a couple people said they preferred using US:US:BUS, there are no instances of that in the current database. It's possible they used to exist but have been since changed, but I can't tell that one way or the other. That notwithstanding, I've gone back and looked through all the past discussions about route relation networks that I can find and it seems that almost everyone who expresses a preference prefers to view routes with modifiers as subsets of the main network and put the modifier in the network tag. With my data consumer hat on, I'm inclined to agree: although there are drawbacks to both approaches, I feel there are fewer inherent in the network-with-modifiers way. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Volt egy brilló's, a csuszbugó Gimbelt és gált távlengibe, Minden mimicre purrogó, Mómája ingibe. -- Lewis Carroll, Jabberwocky --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-03 07:21 -0700]: Also curious how some of the more interesting edge cases work out, such as Missouri Secondary State Highways Someone seems to have made route relations for a lot of these already, with a network of US:MO:Supplemental, so that's what I chose to key off of. Oregon/Washington/Oklahoma State Tour Routes Not currently supported. Can you point me at some information about these? Oklahoma/Kansas Turnpike There's support for the Kansas Turnpike, but it's not rendered because the route relation doesn't have a network on it. (I don't trust every named highway with its own shield to have a globally unique name, so I key off the network, which in most cases I expect to be the same as the main state network.) I'll have to add the Chikasaw Turnpike; I don't see any information about shields for the other Oklahoma turnpikes on Wikipedia. or the 7 state highway networks in Texas that aren't Texas... Mostly I've followed the networks already in use: US:TX, US:TX:LOOP, US:TX:SPUR, US:TX:FM, US:TX:RM, US:TX:FM:Business, US:TX:NASA, US:TX:PR, some others. A lot of those still don't render because they duplicate the subnetwork in the ref tag, so Loop 5 (picking an arbitrary number) might be represented as network=US:TX:LOOP, ref=5 Loop. Once the ref is changed to a plain 5, it would be rendered properly. I chose to treat the Old San Antonio Road as a member of the US:TX network with a ref of OSR. I can't remember if it renders that way at the moment. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Meow translates as, Come here. I want to ignore you. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-03 07:23 -0700]: On Tue, Apr 3, 2012 at 3:40 AM, Alexander Jones happy5...@gmail.com wrote: Rosecrans is technically no longer a state highway, as CA 209 was decommissioned in 2003. I could take another look at 75 when the database is editable again. Correct me if I'm wrong, but only routes with relations render with shields, right? Right. If a way has a ref tag but is not in a route relation, it gets an old-style shield that looks the same as it would be on the main OSM rendering. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Have you never thought as you read that months may lie between any pair of words? -- Gene Wolfe --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Chris Lawrence lordsu...@gmail.com [2012-04-03 10:21 -0400]: - Secondaries (network US:VA:secondary) don't seem to be rendering at all, and the fallback shields aren't showing up even where there are ref tags (just seems to be using Mapnik style). Simple rule for VA: if the ref = 600, or it has a letter in it, it's a secondary (except 785 and 895, which are signed primary). 1 = 599 are primary. When we looked at the database, we saw some secondary routes tagged as US:VA and some as US:VA:Secondary. Since there didn't seem to be any overlap in the numbering, we chose to only look for the US:VA network and render either a primary or secondary shield based on the number. I assume you live in Virginia. What do you, as a resident, think of this rendering choice? Separately, Mapnik ought to be using the fallback shields when it doesn't place one of our shields. It might be getting confused by the presence of the US:VA:secondary route even though there aren't any shields for it. I'll look into it. - The US 460 business route doesn't seem to be getting shields. We're looking for US Business routes under a network of US:US:Business. It probably isn't tagged that way. Once it is, it'll show up. Also, a more general comment - I think concurrencies might look better stacked vertically in some circumstances... you'd have to have some logic about the underlying direction of the way to make that happen, but vertical stacking would look nicer on N-S ways I think. Someone else had a similar comment. I'm pondering ways of matching the major axis of the shield clustering to the general direction of the way. I don't think I can get this perfect in all circumstances: without some alteration to mapnik's code, I think the best I can do is to get the overall orientation of a way in its entirety. That will be good enough for a lot of cases, but if a way has a north-south section, then a curve, then an east-west section, it's probably going to come out with a diagonal orientation. I'm going to do some test renderings and see how good I can make it look. I-26 in TN seems to be missing: http://elrond.aperiodic.net/shields/?zoom=11lat=36.35713lon=-82.42503layers=B0 The route relation has I 26 in the ref tag. Once it's change to just 26, it'll render properly (although it'll take until the next time we run the cluster generating script after that change before it'll show up in concurrencies). Similarly, while the 4-way US multiplex over the old bridge in Memphis is rendered fine, I-55 seems to be missing in both AR and TN (but is OK in MS): http://elrond.aperiodic.net/shields/?zoom=14lat=35.1354lon=-90.07954layers=B0 It's the same thing. The route relation for I-55 has I 55 in the ref tag. Looks great so far otherwise - keep up the good work! Thanks! -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- If you employ people as advisors, listen to their advice. -- Evil Overlord's Handbook, entry 17 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-03 08:57 -0700]: Oregon/Washington/Oklahoma State Tour Routes Not currently supported. Can you point me at some information about these? I don't think there's been a real effort to tag these yet, the four in Oregon I'm aware of are the Lewis Clark Trail, Oregon Trail, California (aka Applegate) Trail and the Oregon Outback Route. Each of the first three seem to use their own trailblazers and may be interstate in scope. The latter and newer routes use extremely large trailblazers. http://www.examiner.com/images/blog/wysiwyg/image/Oregon-Outback-Sign.jpg I've added those to the TODO list. I'll have to see if I can find example images for most of them, and the Oregon Outback Route's image may prove to be too much for my meager artistic ability. (I've mostly been working off of public domain images from Wikipedia.) All of Oklahoma's turnpikes use identical trailblazers, the only part that changes is the name on the top half of the roundel (in this case, Indian Nations). http://www.aaroads.com/shields/show.php?image=OK20060731 Ah, okay. I'll set them up just like other named-but-not-publically-numbered routes like the New Jersey Turnpike and look for network US:OK, no ref, and whetever their name is. FM and RM should render identically (obviously since they're actually the same network), LOOP, SPUR, NASA, Texas I all recognize. I don't see TOLL or REC, and no idea what PR is... As NE2 said, FM and RM differ in the text on the image, though the rendered shields are too small to be able to tell. We do have US:TX:Toll and US:TX:RE also. PR is Park Road. As I said, most of them don't render at the moment (aside from the US:TX roads), but there are some ranch-to-market roads that show up, like here: http://elrond.aperiodic.net/shields/?zoom=14lat=30.4855lon=-99.44341layers=B0 I chose to treat the Old San Antonio Road as a member of the US:TX network with a ref of OSR. I can't remember if it renders that way at the moment. Ah. It does. http://elrond.aperiodic.net/shields/?zoom=14lat=30.98139lon=-96.2095layers=B0 -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- The Macintosh mouse is really a three-button mouse, except they hid two of the buttons on the keyboard. -- Ted Nelson --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Minh Nguyen m...@1ec5.org [2012-04-03 09:36 -0700]: INDIANA and possibly others would be more legible in a wider font. There's still space on either side to accommodate the text. Only on the wide-format shields. On the narrower ones used for two-digit numbers, the name runs right to the edge. If the FHWA fonts don't work out, you could always resort to a bitmap font. That's a longer-term possibility. I'd like the shields to look good when scaled to any size, which is why the templates are all SVGs that get turned into PNGs only at the last possible moment. Bitmap fonts tend to look good at exactly one resolution, so I'd have to figure out a good way to dynamically choose the font characteristics based on the target rendering size. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- #define BITCOUNT(x) (((BX_(x) + (BX_(x) 4)) 0x0f0f0f0f) % 255) #define BX_(x) ((x) - (((x) 1) 0x)\ - (((x) 2) 0x)\ - (((x) 3) 0x)) /* Counts the number of bits in a word. */ --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-03 11:44 -0400]: On 4/3/2012 11:19 AM, Phil! Gold wrote: A lot of those still don't render because they duplicate the subnetwork in the ref tag, so Loop 5 (picking an arbitrary number) might be represented as network=US:TX:LOOP, ref=5 Loop. Once the ref is changed to a plain 5, it would be rendered properly. You mean *if* the ref is changed. Perhaps the locals want to keep the Loop in the ref tag. Point taken. They will appear on our particular rendering if the locals choose to change the tagging. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- No, being mentioned on my website doesn't necessarily disqualify you from getting a government job. -- vees --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Paul Johnson ba...@ursamundi.org [2012-04-03 08:59 -0700]: That just reminded me... Chicago and Tulsa have city routes. I'm planning on looking at city routes after we sort out county routes. And these edge cases (city routes and state secondary/supplemental routes, especially oddball (Oregon) and extreme (Texas) cases) make for great prepwork to render cycleway network trailblazers (which tend towards obscenely diverse in much of the US). Rendering cycleway shields is a long-term idea I'd like to do. (I hadn't really been thinking about them until some point after I started working on the highway shields when I went hiking along part of the Northern Central Railroad Trail and saw that not only was it part of the East Coast Greenway, the East Coast Greenway had its own marker shield.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Je svacxvecxer. Lysperní jezeleni se vírnex vrtácxejí v mokrxavex. Vetcharxí hadrousxci jsou roztruchleni a selvy sysxtí tesknoskuhravex. -- Lewis Carroll, Jabberwocky --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Nathan Edgars II nerou...@gmail.com [2012-04-03 13:36 -0400]: On 4/3/2012 12:52 PM, Phil! Gold wrote: Point taken. They will appear on our particular rendering if the locals choose to change the tagging. So you'll include network=US:US ref=17 Truck as acceptable tagging? Since I'm local to said route. If you want to tag your local routes that way, I won't stop you. But I don't want to have to deal with multiple tagging standards and it seems to me that there's a consensus on this list that network=US:US:Truck, ref=17 is the better approach, so that's what I will focus on rendering. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- If you can read this, you're not illiterate. Good for you. -- Bumper sticker slogan --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Shield Rendering
* Chris Lawrence lordsu...@gmail.com [2012-04-03 15:15 -0400]: As NE2 correctly points out, the number may not be the best guide. VA secondaries are a lot more like CR systems in other states or the secondary system in Missouri, in that the numbering doesn't carry between counties/cities (e.g. there are probably almost* as many SR 600s as there are counties in the state). My tagging has been to use US:VA:secondary to avoid ambiguity, with separate relations for each distinct secondary using is_in:county for disambiguation. Okay. If there aren't any strenuous objections from other Virginians on the list, I'll go with US:VA:Secondary for the secondary routes and won't render them if they're tagged US:VA. Finally, if you get bored, I wouldn't mind seeing a more commercial map style rendering option more akin to what Mapquest is doing - e.g. using the US and I shields but just circles/lozenges for the (primary) state routes and squares/rectangles for secondaries/CRs/Texas weirdness. After what you've done so far that will probably be child's play. :) Yes, part of what we're doing here is seeing just how far we can go with this approach, complete with all the one-off shields that roads around the country use. I think that doing a proper commercial style will actually require some additional tagging--I think we need a network_level tag akin to the admin boundaries' admin_level so data consumers don't have to know about every possible network value in every jurisdiction--and eventually I'll get around to writing up a proposal if no one beats me to it. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Absence is to love what wind is to fire. It extinguishes the small; enkindles the great. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Highway Shield Rendering
Here's something that might be a diversion while you wait for the database to allow editing again. Richard Weait and I have been working on a rendering that uses route relations to make individual shields that reflect what each state uses. I've got a working prototype, and I'd like to get some feedback on it. The server is a rather slow one sitting at my place behind a slow-ish DSL connection, which means that it'll probably range from a little slow to very slow indeed. I'm working on getting some better hosting for it. If you're not yet deterred, I invite you to look at http://elrond.aperiodic.net/shields/ . The code and source files are at https://launchpad.net/osm-shields . I haven't yet written up the details about what works or doesn't but the basic gist is that we use the network= and ref= tags on the relation and, if there's no ref= tag, use the name= tag so we can get things like the New Jersey Turnpike, which has a name but no signed number. Business and similar variants are expected to be in the network tag, since that's the closest thing I've seen to a consensus on the topic. If there's no route relation or the tagging was not understood, we fall back to rendering the ref= tag on the way just like the main OSM rendering. There are actually two shield styles we have. There's the cutout-style that you see by default and another style you can switch to that more closely resembles the roadside reassurance signs for the routes. The cutouts will probably load faster--more of them have been rendered already--but please take a look at the other one, too; I'd like to know which one people prefer. I'm not an expert on every state, so I'm particularly interested in whether things look good to the natives of each state and, if not, what could make them look better. If you just want to look around, here are some spots you might find interesting: * The greatest concurrency in the US is an 8-plex in Indiana: http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0 * New Jersey has several highways with their own shields. You can see both the New Jersey Turnpike and the Garden State Parkway here: http://elrond.aperiodic.net/shields/?zoom=12lat=40.53314lon=-74.31054layers=B0 * Many states have boring rectangles for their shields. Some have interesting shields with details that don't really come out with our rendering. Two of the more visually interesting states that we do show are, I think, Washington and Utah: http://elrond.aperiodic.net/shields/?zoom=12lat=40.53314lon=-74.31054layers=B0 http://elrond.aperiodic.net/shields/?zoom=11lat=40.6916lon=-111.90163layers=B0 * Even Washington DC has its own shield design, but there's only one road with that sign, DC 295 (which is a connector between MD 295 and I-295): http://elrond.aperiodic.net/shields/?zoom=14lat=38.88345lon=-76.9615layers=B0 So be patient with it if the tiles load slowly and please let me know what you think! -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- ...And the lord said, 'lo, there shall only be case or default labels inside a switch statement.' -- Apple MPW C Compiler error message --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us