Re: [Talk-us] Route Tagging Consensus
On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson ba...@ursamundi.org wrote: On 10/25/2010 08:43 AM, Zeke Farwell wrote: For Michigan route 12: ref=12 network=state state=michigan For Bennington County route 16 in Vermont: ref=16 network=county state=vermont county=bennington I like it, though it should be pointed out that this is more difficult unless we're talking about route relations. I kind of like this system as well. It is clear and easy to understand. The only problem (as pointed out before) is that it breaks the network tag compared to the rest of the world. Can we use it anyway? :) Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: On Tue, Oct 26, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: Second, let's decide if we should render the route numbers in route-type specific shields. I think that we should do so. Let's not let Google, MapQuest and Bing be a ceiling, but instead a floor. No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. These were both reduced to bitmaps using the SVG file you gave me using Inkscape. If there are any shields that don't work well this way, the blank shields can be redrawn manually. The same for any unclear digits. Then the renderer can put these pieces together. But this is only if the simple solution (demonstrated by the attachments) doesn't work. Any other objections to my suggestion? - Val - attachment: Colorado_7.svgattachment: Colorado_7-20.png___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] [Fwd: Re: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)]
Oops! I attached the SVG and the 20x20 image (1/20th original size). I meant to attach the 39x39 image (1/10th original size). Here it is. ---BeginMessage--- On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: On Tue, Oct 26, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: Second, let's decide if we should render the route numbers in route-type specific shields. I think that we should do so. Let's not let Google, MapQuest and Bing be a ceiling, but instead a floor. No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. These were both reduced to bitmaps using the SVG file you gave me using Inkscape. If there are any shields that don't work well this way, the blank shields can be redrawn manually. The same for any unclear digits. Then the renderer can put these pieces together. But this is only if the simple solution (demonstrated by the attachments) doesn't work. Any other objections to my suggestion? - Val - attachment: Colorado_7.svgattachment: Colorado_7-20.png---End Message--- attachment: Colorado_7.png___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
* Val Kartchner val...@gmail.com [2010-10-25 22:45 -0600]: Second, let's decide if we should render the route numbers in route-type specific shields. I think that everyone agrees with this. The problem is that it's somewhat difficult with our rendering toolchain. There are, however, people working on it. My quesion is more or less how people would like to go about tagging refs for the textual rendering we currently have so that we're at least consistent across the entire nation. I specifically envision this as a temporary improvement until we get proper shield rendering, but I think we really need to clean up the mess we have 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 --- -- A man was reading The Canterbury Tales one Saturday morning, when his wife asked What have you got there? Replied he, Just my cup and Chaucer. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate exit junction tagging
* Mike N. nice...@att.net [2010-10-25 21:44 -0400]:
Since I believe the name={signInfo] is a US-only convention and there
are no other strong opinions, we should look at changing this.
I like the idea of putting the immediately-connected road in the exit_to=
tag and leaving the rest of the sign's text to destination sign relations.
I fully agree that some people's current practice (including mine in the
past) makes for a very clittered map and needs improvement.
--
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2
--- --
Facts do not cease to exist because they are ignored.
-- Aldous Huxley
--- --
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] stop signs
Therefor I propose stop signs go on the intersection and save a lot of hassle with the tag highway=stop I think your proposal can work, but you need to show how e.g. to mark 2 out of 5 roads at an intersection. Also, roads are directional even if 2way so we could allow stop on nodes on ways to be stop=forward and stop=reverse, but I agree this starts to feel too hard. Sort of related, I have been thinking that code to gather typical speeds and now stop signs from traces would be a great addition. pgpe2wOCKSfqn.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate exit junction tagging
I like the idea of putting the immediately-connected road in the exit_to= tag and leaving the rest of the sign's text to destination sign relations. I fully agree that some people's current practice (including mine in the past) makes for a very clittered map and needs improvement. Interstate exit signs are carefully chosen for clarity - using only the immediately-connected road in exit_to can result in a situation such Tulsa, OK where Skelly Drive parallels I44, and there would be many exits with an immediate link to Skelly Drive: http://www.openstreetmap.org/?lat=36.0895lon=-95.95508zoom=16layers=M - totally confusing someone who uses that information. Sign relations are less ambiguous, but there is no editor assistance. In many cases, a destination city on a sign will be hundreds of KM distant, which again complicates trying to locate the object to add to the sign relation. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] stop signs
On Tue, Oct 26, 2010 at 8:19 AM, Greg Troxel g...@ir.bbn.com wrote: Therefor I propose stop signs go on the intersection and save a lot of hassle with the tag highway=stop I think your proposal can work, but you need to show how e.g. to mark 2 out of 5 roads at an intersection. I think that 4-way and 3-way stops can be handled unambiguously by highway=stop. More complex stops should probably be modeled with turn restrictions. type=restriction restriction=stop roles=from,to,via A 4-way intersection where 2 opposites stop, A B, and one continues, C/or D, through, E, can be modeled with a single relation. Eg: from:A from:B to:C to:D via:E 3-ways with a single stop can be done similarly. Cheers, Adam ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
Toby Murray toby.mur...@gmail.com writes: On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson ba...@ursamundi.org wrote: On 10/25/2010 08:43 AM, Zeke Farwell wrote: For Michigan route 12: ref=12 network=state state=michigan For Bennington County route 16 in Vermont: ref=16 network=county state=vermont county=bennington I like it, though it should be pointed out that this is more difficult unless we're talking about route relations. I kind of like this system as well. It is clear and easy to understand. The only problem (as pointed out before) is that it breaks the network tag compared to the rest of the world. Can we use it anyway? :) What about making it network=US:state or network=US:county? That way it's easy to tell US states apart from states in other countries. Does that ruin its simplicity and elegance? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, Oct 26, 2010 at 3:17 AM, Val Kartchner val...@gmail.com wrote: On Tue, 2010-10-26 at 01:27 -0400, Nathan Edgars II wrote: No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. It's actually 17x17 that you want: http://upload.wikimedia.org/wikipedia/commons/thumb/b/b8/Colorado_7.svg/17px-Colorado_7.svg.png and this is somewhat harder to make out than Mapnik's 7 in a circle: http://www.openstreetmap.org/?lat=26.6963lon=-80.1974zoom=14layers=M And Mapnik's default shield actually has a bit of padding; the number itself is in a 13x13 space. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] stop signs
On Tue, Oct 26, 2010 at 8:36 AM, Adam Schreiber sa...@clemson.edu wrote: I think that 4-way and 3-way stops can be handled unambiguously by highway=stop. More complex stops should probably be modeled with turn restrictions. type=restriction restriction=stop roles=from,to,via But a stop sign isn't a restriction; it has the main effect of slowing average speed. If our router is so precise that the seconds added by a stop sign count, it can easily calculate the nearest intersection to each stop sign node to figure out the likely direction. But for practical purposes simply halving the number of stop sign nodes passed should be enough. What's wrong with something like highway:forward=stop or highway:backward=stop for the node where one must stop? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] stop signs
On Tue, Oct 26, 2010 at 10:17 AM, Nathan Edgars II nerou...@gmail.com wrote: What's wrong with something like highway:forward=stop or highway:backward=stop for the node where one must stop? How does that capture intersections where one of the roads entering and exiting the junction node doesn't stop? Are you suggesting that highway=stop be added to the node before the junction? Cheers, Adam ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] stop signs
On Tue, Oct 26, 2010 at 10:17 AM, Nathan Edgars II nerou...@gmail.com wrote: But a stop sign isn't a restriction; it has the main effect of slowing average speed. If our router is so precise that the seconds added by a stop sign count, it can easily calculate the nearest intersection to each stop sign node to figure out the likely direction. +1 Also, the number of seconds to add would vary drastically, sometimes even within the same intersection. I'd very much like to add a large penalty for making a left turn at a particular intersection exiting my development, but not add much of a penalty for making a left at a different intersection, or making a right at either of them. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, Oct 26, 2010 at 11:46 AM, Alex Mauer ha...@hawkesnest.net wrote: On 10/26/2010 09:11 AM, Nathan Edgars II wrote: Attached are the bitmaps of the shield that is poorly-designed for display in a limited number of pixels. The first one is 39x39 pixels, and the second is 20x20 pixels. Both are quite readable. It's actually 17x17 that you want: http://upload.wikimedia.org/wikipedia/commons/thumb/b/b8/Colorado_7.svg/17px-Colorado_7.svg.png Where does this number come from? The actual size of a circular 7 shield generated by Mapnik. Is it not possible to render an icon at any size we want? Yes, if it’s too big it will not work on the map, but I think 20×20 is quite reasonable (and readable). It's a tradeoff where bigger shields reduce the space for other features. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On 10/26/2010 10:50 AM, Nathan Edgars II wrote: The actual size of a circular 7 shield generated by Mapnik. Yeah, but is it set in stone that it Cannot Be Larger Than It Is Now? I doubt it. And I feel that gaining the ability to have state-specific shields is worth giving up a tiny bit of space. Is it not possible to render an icon at any size we want? Yes, if it’s too big it will not work on the map, but I think 20×20 is quite reasonable (and readable). It's a tradeoff where bigger shields reduce the space for other features. Sure, but that doesn’t mean that we can’t adjust to give a little more space to highway shields. Not that we have to or should follow the lead of other map sites, but it seems like 17×17 is a pretty bare minimum. Mapquest US highway: 24×22 Mapquest Interstate: 22×23 Mapquest generic state: 22×18 Google US highway: 22×22 Google Interstate: 20×21 Google generic state: 24×16 Yahoo US highway: 17×17 Yahoo Interstate: 17×18 Yahoo generic state: 22×13 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, Oct 26, 2010 at 1:02 PM, Alex Mauer ha...@hawkesnest.net wrote: On 10/26/2010 10:50 AM, Nathan Edgars II wrote: It's a tradeoff where bigger shields reduce the space for other features. Sure, but that doesn’t mean that we can’t adjust to give a little more space to highway shields. These rendering decisions are completely unrelated to the discussion of how shields might best be tagged. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On 10/26/2010 12:15 PM, Richard Weait wrote: These rendering decisions are completely unrelated to the discussion of how shields might best be tagged. This portion of the thread clearly moved on to a different but related topic as soon as someone said “Some shields are poorly-designed for display in a limited number of pixels”. Thanks though. —Alex Mauer “hawke” ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, Oct 26, 2010 at 1:21 PM, Alex Mauer ha...@hawkesnest.net wrote: On 10/26/2010 12:15 PM, Richard Weait wrote: These rendering decisions are completely unrelated to the discussion of how shields might best be tagged. This portion of the thread clearly moved on to a different but related topic as soon as someone said “Some shields are poorly-designed for display in a limited number of pixels”. Thanks though. It moved when someone said let's decide if we should render the route numbers in route-type specific shields. As for the question of tagging, basically you can use relations, or you can hack something up to simulate relations (specifically, to handle the very common situation where there is more than one route using the same way) without actually using relations. Then there's the trivial question as to whether to include the prefix along with the route number, or to store it separately. The answer: it doesn't matter. Pick one. Flip a coin. Do a survey to see which is more common. Who cares? Then there's the question of how to render it. Probably something to discuss on a different list, like a mapnik-specific one. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On 10/26/2010 12:42 PM, Anthony wrote: As for the question of tagging, basically you can use relations, or you can hack something up to simulate relations (specifically, to handle the very common situation where there is more than one route using the same way) without actually using relations. I haven’t seen anyone say that route relations are not the way to go. Have you? Then there's the question of how to render it. Probably something to discuss on a different list, like a mapnik-specific one. Why? It’s a mostly US-specific problem, though I hear that at least shield rendering is also desired in Australia. —Alex Mauer “hawke” ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
On Tue, Oct 26, 2010 at 2:06 PM, Alex Mauer ha...@hawkesnest.net wrote: On 10/26/2010 12:42 PM, Anthony wrote: As for the question of tagging, basically you can use relations, or you can hack something up to simulate relations (specifically, to handle the very common situation where there is more than one route using the same way) without actually using relations. I haven’t seen anyone say that route relations are not the way to go. Have you? I've seen dispute as to whether or not there's a need to invent an interim solution. Then there's the question of how to render it. Probably something to discuss on a different list, like a mapnik-specific one. Why? It’s a mostly US-specific problem, though I hear that at least shield rendering is also desired in Australia. I get the feeling that on a mapnik list you'll get more people who care about how mapnik renders things. But maybe I'm wrong about that. If so, hopefully you can at least keep the mapnik-specific discussion in a separate thread, for those of us who couldn't care less about mapnik. (I also think the mapnik-specific discussion would benefit from people who understand what mapnik is capable of, and how difficult it would be to implement various suggestions, regardless of whether or not the people with that expertise care about the US.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
Is there a reason to have the network tag with networkUS:state:county instead of three separate tags for network:country network:state and network:county in the case of county roads and two in the case of state, etc. Having a network:country= tag will clear up any confusion in which country the route is in. I don't think a simple US:state:county tag will suffice as people have complained about parsing. Such a tag would likely have to be tagged network:location=US:state:county as you would have to differentiate between interstates, highways, etc. easily. By having a network and location tags you could know the location and type of road. Additionally this would allow for rendering of shields or determining the type route for other rendering differentiation purposes. I think because other tags break out location based on country, state, county, etc it would be wise to also do so with network tagging. There are many counties that have the same name that are in different locations. Other OSM users have expressed issues with relying on pre-possessing to gather location data. Andrew On Tue, Oct 26, 2010 at 09:57, Peter Budny pet...@gatech.edu wrote: Toby Murray toby.mur...@gmail.com writes: On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson ba...@ursamundi.org wrote: On 10/25/2010 08:43 AM, Zeke Farwell wrote: For Michigan route 12: ref=12 network=state state=michigan For Bennington County route 16 in Vermont: ref=16 network=county state=vermont county=bennington I like it, though it should be pointed out that this is more difficult unless we're talking about route relations. I kind of like this system as well. It is clear and easy to understand. The only problem (as pointed out before) is that it breaks the network tag compared to the rest of the world. Can we use it anyway? :) What about making it network=US:state or network=US:county? That way it's easy to tell US states apart from states in other countries. Does that ruin its simplicity and elegance? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible method for identifying major US cities
* Nathan Edgars II nerou...@gmail.com [2010-10-25 21:39 -0400]: I've done it in Florida. Here's the algorithm I used: principal city of a Metropolitan Statistical Area: city principal city of a Micropolitan Statistical Area: town other incorporated municipality with population over 10,000: suburb (these are all inside statistical areas) other incorporated municipality with population under 10,000: village, hamlet, or (in the case of Islandia) locality (according to the cutoffs on http://wiki.openstreetmap.org/wiki/Key:place) other unincorporated places: left alone for now I mostly like this, but I feel somewhat constrained by the place= values for some of this. I went over the classifications that this would make in Maryland and agreed with most of it, except that I'd really like another value above place=city. This algorithm would mark Arlington, VA; Alexandria, VA; Reston, VA; Bethesda, MD; Rockville, MD; Frederick MD; and Gaithersburg, MD as cities, in addition to Washington, DC. That's pretty fair, considering those places' populations and economic importance, but DC should be ranked a step higher than the rest. Likewise, it would make Baltimore and Towson both cities and, while making Towson a city is not unfair, Baltimore is far more important a place than Towson is. (For one thing, people from other states are much more likely to have heard of Baltimore.) I've been thinking a lot about city importance since I read http://www.41latitude.com/post/1178194590/jaywalking and http://www.41latitude.com/post/400972984/most-important-cities-united-states . I think I'm mostly of the mind that OSM's basically four-tier system (city, town, village, hamlet) system isn't granular enough for properly indicating cities' importance relative to each other. I think some of the general importance tagging ideas that have been floated might help with this. If I have time, I might see about getting them on the proposal track actively, rather than languishing. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I parry the demon's two-handed sword with my stiletto. -- Famous Last Words, #731 --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
Andrew S. J. Sawyer assaw...@gmail.com writes: Is there a reason to have the network tag with networkUS:state:county instead of three separate tags for network:country network:state and network:county in the case of county roads and two in the case of state, etc. Having a network:country= tag will clear up any confusion in which country the route is in. I don't think a simple US:state:county tag will suffice as people have complained about parsing. Such a tag would likely have to be tagged network:location=US:state:county as you would have to differentiate between interstates, highways, etc. easily. By having a network and location tags you could know the location and type of road. Additionally this would allow for rendering of shields or determining the type route for other rendering differentiation purposes. I think because other tags break out location based on country, state, county, etc it would be wise to also do so with network tagging. There are many counties that have the same name that are in different locations. Other OSM users have expressed issues with relying on pre-possessing to gather location data. I may not have been very clear... if that's the case I apologize. What I meant was, is there a way to include just a little more information so that we can distinguish between, say, US states and Mexican states. If the tags only say network=state and state=* we lose some information. My proposal was to have network=US:state (literally, not putting the state name there) and state=*. However, I think your idea may be a better one. It would give us network=state network:country=US network:state=California or network=county network:country=US network:state=California network:county=Orange I support something like this because it gives us enough information that we can pretty easily convert to another format (relations, or some other tag representation) later with automated tools. And it makes querying easier, since you don't have to do polygon searches to figure out whether e.g. the route it part of a US state or a Mexican state. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible method for identifying major US cities
Phil! Gold phi...@pobox.com writes: * Nathan Edgars II nerou...@gmail.com [2010-10-25 21:39 -0400]: I've done it in Florida. Here's the algorithm I used: principal city of a Metropolitan Statistical Area: city principal city of a Micropolitan Statistical Area: town other incorporated municipality with population over 10,000: suburb (these are all inside statistical areas) other incorporated municipality with population under 10,000: village, hamlet, or (in the case of Islandia) locality (according to the cutoffs on http://wiki.openstreetmap.org/wiki/Key:place) other unincorporated places: left alone for now I mostly like this, but I feel somewhat constrained by the place= values for some of this. I went over the classifications that this would make in Maryland and agreed with most of it, except that I'd really like another value above place=city. This algorithm would mark Arlington, VA; Alexandria, VA; Reston, VA; Bethesda, MD; Rockville, MD; Frederick MD; and Gaithersburg, MD as cities, in addition to Washington, DC. That's pretty fair, considering those places' populations and economic importance, but DC should be ranked a step higher than the rest. Likewise, it would make Baltimore and Towson both cities and, while making Towson a city is not unfair, Baltimore is far more important a place than Towson is. (For one thing, people from other states are much more likely to have heard of Baltimore.) I've been thinking a lot about city importance since I read http://www.41latitude.com/post/1178194590/jaywalking and http://www.41latitude.com/post/400972984/most-important-cities-united-states . I think I'm mostly of the mind that OSM's basically four-tier system (city, town, village, hamlet) system isn't granular enough for properly indicating cities' importance relative to each other. I think some of the general importance tagging ideas that have been floated might help with this. If I have time, I might see about getting them on the proposal track actively, rather than languishing. Martin and I had a discussion (was it on this list?) about this, and I think we agreed that the place=* tag isn't really very helpful. It's just too coarse-grained, and it can't be tuned for producing different types of maps. The idea we started thinking about is to have tags (on the city node, or way, or relation) that give a whole bunch of statistics that might be relevant for determining how important a city is, which would determine at what zoom level it shows up and how big its label should be. Not to say that the place=* tag should go away, but I'd like to see it relegated to being nothing more than a 'suggestion' for less featureful renderers. Any serious map rendering ought to be more flexible than just 4 arbitrary sizes of cities/towns assigned manually. (My sole complaint about the idea, really, was that having tags in OSM for information like population which could theoretically be culled from other sources automatically is kind of redundant and thus troublesome... except that we'd have to have so many data sources (one per country, roughly) that it would be impossible to maintain. So just sticking it in tags and updating it manually/semi-automatically is probably okay.) -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
