Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On 03/23/2015 12:29 PM, Bryce Nesbitt wrote: The nice thing about mapping a neighborhood name as a point feature is: a) It helps people locate the neighborhood b) it completely sidesteps the question of the exact, possibly fuzzy, boundaries. For 10% of the hassle you map 90% of the benefit. Or follow the obvious rule: Let the local mappers decide. Use point features for indeterminate things. In areas where neighborhoods have borders that are identifiable on the ground, map the borders. Some neighborhoods are gated. Some are signed. Some, all the locals understand, are bounded by major streets. Many subdivisions, even if not signed, have homogeneous enough architecture that the borders are obvious. And some cities try to foster neighborhood identity and specifically identify neighborhoods, even where the neighborhoods are not legal political entities. Don't decide as an armchair mapper that you know better than the locals. This goes double for using a mechanical edit to fix what the locals have done. Fix only what you can see is wrong on the ground (or what you can't see on the ground at all). This sort of fixing requires boots on the ground. (I'm willing to allow an exception for repairing the damage done by ill-advised mechanical edits - but only after consultation with the locals.) -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retagging hamlets in the US
2015-03-22 4:00 GMT+01:00 Clifford Snow cliff...@snowandsnow.us: At its most basic, OSM is a geospatial database. We have countries, states, counties, and cities. Why not neighborhoods. OSM tells where a feature is located. Points can only tell us how close a feature is to a node. Using nodes to represent neighborhoods doesn't allow with any certainty where a feature is located while a polygon can. +1 Cheers, Martin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
I would politely disagree that TIGER is an authoritative source for two reasons: 1) The extensive TIGER cleanup that is still being done years after the last import, and 2) While helpful at compiling data, the federal government is not authoritative for any boundaries within a state (and once established, not even for the boundaries of the states themselves). -jack On March 24, 2015 4:57:44 PM EDT, Martijn van Exel mart...@openstreetmap.us wrote: there is an authoritative source for official administrative boundaries that can be easily accessed by anyone: TIGER -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On 3/24/15 6:01 PM, Jack Burke wrote: I would politely disagree that TIGER is an authoritative source for two reasons: 1) The extensive TIGER cleanup that is still being done years after the last import, and well, if that data were removed and sourced externally, the problems with TIGER boundary data and OSM would change in character rather substantially. 2) While helpful at compiling data, the federal government is not authoritative for any boundaries within a state (and once established, not even for the boundaries of the states themselves). as part of the ongoing improvements in TIGER, the Census Bureau is increasingly pulling data from County GIS departments rather than maintaining it themselves. the quality is much better. and since it's digital, the game of telephone metaphor does not apply so much any more. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Maps and the Geospatial Revolution Coursera class
I'm registered to this online class, it is scheduled to start tomorrow. Perhaps it will be of interest to someone on the list. This course brings together core concepts in cartography, geographic information systems, and spatial thinking with real-world examples to provide the fundamentals necessary to engage with Geography beyond the surface-level. We will explore what makes spatial information special, how spatial data is created, how spatial analysis is conducted, and how to design maps so that they’re effective at telling the stories we wish to share. To gain experience using this knowledge, we will work with the latest mapping and analysis software to explore geographic problems. https://www.coursera.org/course/maps http://www.personal.psu.edu/acr181/GR_MOOC_Course_Outline_121313.pdf Yours, -- Max ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
I noticed that about other items, but the key:ele wiki page defines this clearly: it’s in meters, and this suggests to me that others using 3643_ft or 3643ft are doing it wrong, or at least inconsistently with advertised expectations. If my goal is to just make local maps look nice, I’ll just set the ele = “3643 feet”, but at what point is it detrimental to the project as a whole to go against specific and explicit guidance, such that it will break software that relies on people playing well in the sandbox [by setting numeric meters]. Put another way: am I being selfish to just do it my own way and screw anybody else who’s counting on me to play by the rules? Seems to me that it *is* reasonable to set elevation to include a number + unit of measure, but doesn’t this kind of thing go for a proposal, get input from others who care about the matter, standardize on formats such that validators can validate and harmonize, and go for some kind of vote? I’m much too new to the project to charge ahead I that way, but I do welcome a discussion. Steve From: Harald Kliems [mailto:kli...@gmail.com] Sent: Tuesday, March 24, 2015 7:18 PM To: Steve Friedl; talk-us@openstreetmap.org Subject: Re: [Talk-us] Elevation in local units Hi Steve: one tag where units are in common use is maxspeed. The default is km/h but you can also use mph or knots. I don't see why this wouldn't be feasible for the ele tag as well. If you look at taginfo, you can also see that ft is used quite a bit -- unfortunately often in an inconsistent way, e.g. ele=3643_ft or 3643ft. http://taginfo.openstreetmap.org/keys/ele#values (you have to search for ft in the search box). Harald. On Tue, Mar 24, 2015 at 8:57 PM Steve Friedl st...@unixwiz.net wrote: Hi all, I appreciated being able to join my first Mappy Hour yesterday, though without mic/camera. I’m quite enamoured with this project and hope to fit in with the goals and the vibe. One thing we talked about, and I’d like to explore more formally, is how to deal with elevation in local units. I lead hikes in the local Santa Ana Mountains, and there is not a single person who hikes here, not even those from Europe or those who personally invented the metric system, who thinks of peak elevations in meters. The guides and the maps are all in feet, the surveying markers are in feet, as are the topo maps. This is just a fact of life even if we all [including me] agree that Americans are foolish for not adopting the metric system. An obvious thought is to enter the elevation including the units, so Sierra Peak would show as “3045 feet” rather than “928”, but this won’t work. The wiki page for the “ele” key defines the tag as meters, so it’s reasonable to expect that some software out there relies on this, and it would have no provisions to convert anything on the fly because it ought to expect numeric meters. But even with this aside, that still doesn’t solve the rendering problem: I believe that page tiles are rendered as images, so it’s got to pick *something* for the text, and I don’t think there’s any way of having a user preference to show these things in local units. My suspicion is that there is no easy fix here, but I think a discussion is in order. I’ve added a section to the key:ele page that touches on this, not so much to propose a solution, but to let others with this same issue know that it’s seen as an issue. Ref: http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units Is this kind of thing suitable for the key:ele page? Steve --- Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571 st...@unixwiz.net | Southern California | Windows Guy | unixwiz.net ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
For what it is worth, I’ve become used to looking at distances on topo maps in meters/kilometers as that is what the UTM grid is on USGS topos but I just can’t deal with elevation in meters. Maybe for relative elevations (I’ve got another 500 meters vertical to go is almost okay, but very definitely not for spot elevations. I’ve been using OSM data mashed with DEM data from the USGS to make paper trail maps. DEM data from the USGS is also in meters by the way. What I do is convert the meters to feet in the scripts that pull data the OSM data tables. So my paper maps have contour lines (generated from metric DEM) and spot elevations (from OSM) in feet. It actually is not too hard to do. And it is easiest, at least for me, to just assume that the elevation is in meters rather than having to parse it to find a “ft” suffix. So from my point of view leaving elevation in meters and having the render deal with localization is a reasonable way to go. Cheers, Tod On Mar 24, 2015, at 7:55 PM, Steve Friedl st...@unixwiz.net wrote: I noticed that about other items, but the key:ele wiki page defines this clearly: it’s in meters, and this suggests to me that others using 3643_ft or 3643ft are doing it wrong, or at least inconsistently with advertised expectations. If my goal is to just make local maps look nice, I’ll just set the ele = “3643 feet”, but at what point is it detrimental to the project as a whole to go against specific and explicit guidance, such that it will break software that relies on people playing well in the sandbox [by setting numeric meters]. Put another way: am I being selfish to just do it my own way and screw anybody else who’s counting on me to play by the rules? Seems to me that it *is* reasonable to set elevation to include a number + unit of measure, but doesn’t this kind of thing go for a proposal, get input from others who care about the matter, standardize on formats such that validators can validate and harmonize, and go for some kind of vote? I’m much too new to the project to charge ahead I that way, but I do welcome a discussion. Steve From: Harald Kliems [mailto:kli...@gmail.com] Sent: Tuesday, March 24, 2015 7:18 PM To: Steve Friedl; talk-us@openstreetmap.org Subject: Re: [Talk-us] Elevation in local units Hi Steve: one tag where units are in common use is maxspeed. The default is km/h but you can also use mph or knots. I don't see why this wouldn't be feasible for the ele tag as well. If you look at taginfo, you can also see that ft is used quite a bit -- unfortunately often in an inconsistent way, e.g. ele=3643_ft or 3643ft. http://taginfo.openstreetmap.org/keys/ele#values http://taginfo.openstreetmap.org/keys/ele#values (you have to search for ft in the search box). Harald. On Tue, Mar 24, 2015 at 8:57 PM Steve Friedl st...@unixwiz.net mailto:st...@unixwiz.net wrote: Hi all, I appreciated being able to join my first Mappy Hour yesterday, though without mic/camera. I’m quite enamoured with this project and hope to fit in with the goals and the vibe. One thing we talked about, and I’d like to explore more formally, is how to deal with elevation in local units. I lead hikes in the local Santa Ana Mountains, and there is not a single person who hikes here, not even those from Europe or those who personally invented the metric system, who thinks of peak elevations in meters. The guides and the maps are all in feet, the surveying markers are in feet, as are the topo maps. This is just a fact of life even if we all [including me] agree that Americans are foolish for not adopting the metric system. An obvious thought is to enter the elevation including the units, so Sierra Peak would show as “3045 feet” rather than “928”, but this won’t work. The wiki page for the “ele” key defines the tag as meters, so it’s reasonable to expect that some software out there relies on this, and it would have no provisions to convert anything on the fly because it ought to expect numeric meters. But even with this aside, that still doesn’t solve the rendering problem: I believe that page tiles are rendered as images, so it’s got to pick *something* for the text, and I don’t think there’s any way of having a user preference to show these things in local units. My suspicion is that there is no easy fix here, but I think a discussion is in order. I’ve added a section to the key:ele page that touches on this, not so much to propose a solution, but to let others with this same issue know that it’s seen as an issue. Ref: http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units Is this kind of thing suitable for the key:ele page? Steve --- Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571 st...@unixwiz.net mailto:st...@unixwiz.net | Southern California
[Talk-us] Elevation in local units
Hi all, I appreciated being able to join my first Mappy Hour yesterday, though without mic/camera. I'm quite enamoured with this project and hope to fit in with the goals and the vibe. One thing we talked about, and I'd like to explore more formally, is how to deal with elevation in local units. I lead hikes in the local Santa Ana Mountains, and there is not a single person who hikes here, not even those from Europe or those who personally invented the metric system, who thinks of peak elevations in meters. The guides and the maps are all in feet, the surveying markers are in feet, as are the topo maps. This is just a fact of life even if we all [including me] agree that Americans are foolish for not adopting the metric system. An obvious thought is to enter the elevation including the units, so Sierra Peak would show as 3045 feet rather than 928, but this won't work. The wiki page for the ele key defines the tag as meters, so it's reasonable to expect that some software out there relies on this, and it would have no provisions to convert anything on the fly because it ought to expect numeric meters. But even with this aside, that still doesn't solve the rendering problem: I believe that page tiles are rendered as images, so it's got to pick *something* for the text, and I don't think there's any way of having a user preference to show these things in local units. My suspicion is that there is no easy fix here, but I think a discussion is in order. I've added a section to the key:ele page that touches on this, not so much to propose a solution, but to let others with this same issue know that it's seen as an issue. Ref: http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units Is this kind of thing suitable for the key:ele page? Steve --- Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571 mailto:st...@unixwiz.net st...@unixwiz.net | Southern California | Windows Guy | unixwiz.net ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
Hi Steve: one tag where units are in common use is maxspeed. The default is km/h but you can also use mph or knots. I don't see why this wouldn't be feasible for the ele tag as well. If you look at taginfo, you can also see that ft is used quite a bit -- unfortunately often in an inconsistent way, e.g. ele=3643_ft or 3643ft. http://taginfo.openstreetmap.org/keys/ele#values (you have to search for ft in the search box). Harald. On Tue, Mar 24, 2015 at 8:57 PM Steve Friedl st...@unixwiz.net wrote: Hi all, I appreciated being able to join my first Mappy Hour yesterday, though without mic/camera. I’m quite enamoured with this project and hope to fit in with the goals and the vibe. One thing we talked about, and I’d like to explore more formally, is how to deal with elevation in local units. I lead hikes in the local Santa Ana Mountains, and there is not a single person who hikes here, not even those from Europe or those who personally invented the metric system, who thinks of peak elevations in meters. The guides and the maps are all in feet, the surveying markers are in feet, as are the topo maps. This is just a fact of life even if we all [including me] agree that Americans are foolish for not adopting the metric system. An obvious thought is to enter the elevation including the units, so Sierra Peak would show as “3045 feet” rather than “928”, but this won’t work. The wiki page for the “ele” key defines the tag as meters, so it’s reasonable to expect that some software out there relies on this, and it would have no provisions to convert anything on the fly because it ought to expect numeric meters. But even with this aside, that still doesn’t solve the rendering problem: I believe that page tiles are rendered as images, so it’s got to pick * *something** for the text, and I don’t think there’s any way of having a user preference to show these things in local units. My suspicion is that there is no easy fix here, but I think a discussion is in order. I’ve added a section to the key:ele page that touches on this, not so much to propose a solution, but to let others with this same issue know that it’s seen as an issue. Ref: http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units Is this kind of thing suitable for the key:ele page? Steve --- Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571 st...@unixwiz.net | Southern California | Windows Guy | unixwiz.net ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
- I feel that osm convention should encourage all mappers to specify units (e.g. 22 m). - That whitespace should be allowed (e.g. 22m, 22 m, or even 22 meters). - And that local units should be encouraged (e.g. 22 feet, or 22' 0). The wiki templates, if spruced up, could define the rules uniformly for all keys that take a measurement unit (e.g. height, width, ele, max_height, etc). -- Parsers are cheap. Any parser worth using can convert 22m, 22 m, 22 feet or a variety of reasonable variants. Humans are messy. Forcing them into boxes generally goes badly. --- Specific to the USA: If I'm mapping a 6000 foot sign I sure don't want to enter 1828.8m or worse yet 1828.8. The same goes for anything that takes a unit. maxspeed=88mph is better than maxspeed=88. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retagging hamlets in the US
On Tue, Mar 24, 2015 at 4:41 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-22 4:00 GMT+01:00 Clifford Snow cliff...@snowandsnow.us: At its most basic, OSM is a geospatial database. We have countries, states, counties, and cities. Why not neighborhoods. OSM tells where a feature is located. Points can only tell us how close a feature is to a node. Using nodes to represent neighborhoods doesn't allow with any certainty where a feature is located while a polygon can. Points are too general. Polygons are too specific. Jeeze. One could invent something in between: an approximate radius point or a fuzzy polygon. Please don't assume because your particular neighborhood has (insert one: fuzzy boundaries, exact legal boundaries, well understood boundaries, an edit war about the boundary, a name used only for a railroad outhouse building in 1850) that there is only One True Solution. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Tue, Mar 24, 2015 at 7:46 AM, Kevin Kenny kken...@nycap.rr.com wrote: Or follow the obvious rule: Let the local mappers decide. Use point features for indeterminate things. In areas where neighborhoods have borders that are identifiable on the ground, map the borders. Some neighborhoods are gated. Some are signed. Some, all the locals understand, are bounded by major streets. Many subdivisions, even if not signed, have homogeneous enough architecture that the borders are obvious. And some cities try to foster neighborhood identity and specifically identify neighborhoods, even where the neighborhoods are not legal political entities. Don't decide as an armchair mapper that you know better than the locals. This goes double for using a mechanical edit to fix what the locals have done. Fix only what you can see is wrong on the ground (or what you can't see on the ground at all). This sort of fixing requires boots on the ground. (I'm willing to allow an exception for repairing the damage done by ill-advised mechanical edits - but only after consultation with the locals.) +1 -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
I have long been on the fence about boundaries in OSM, and while I don't feel as strongly about it any longer, it still feels wrong to make this sweeping exception to one of the fundamental conventions of OSM mapping: verifiability. For many types of land use, anyone would be able to verify boundaries on the ground: a forest, a corn field, even a retail zone in most cases. But administrative boundaries can only be observed in a limited number of places: wherever there is a sign or a physical boundary in place, and rare other cases. More importantly though, there is an authoritative source for official administrative boundaries that can be easily accessed by anyone: TIGER[1] All of this has little to do with neighborhoods, which are mostly (?) vernacular in naming and delineation, and even when there are official neighborhood designations, in my own experience they do not always match the vernacular names. I support point mapping of vernacular neighborhoods. If you really want to have shapes for vernacular neighborhoods, you can look at the now-ancient-but-still-cool flickr Alpha Shapes[2], last updated in 2011 but still available for download[3]. But please don't upload 'em to OSM :) [1] https://www.census.gov/geo/maps-data/data/tiger-cart-boundary.html [2] http://code.flickr.net/2008/10/30/the-shape-of-alpha/ [3] http://code.flickr.net/2011/01/08/flickr-shapefiles-public-dataset-2-0/ Martijn van Exel Secretary, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ skype: mvexel On Mon, Mar 23, 2015 at 11:39 AM, Clifford Snow cliff...@snowandsnow.us wrote: On Mon, Mar 23, 2015 at 10:29 AM, Bryce Nesbitt bry...@obviously.com wrote: The nice thing about mapping a neighborhood name as a point feature is: a) It helps people locate the neighborhood b) it completely sidesteps the question of the exact, possibly fuzzy, boundaries. For 10% of the hassle you map 90% of the benefit. Except when it reports you are in a different neighborhood than you actually are. When neighborhoods are not clearly defined then yes, a point is the best choice. But when neighborhoods have defined boundaries then they should be added. Just going up the admin level to city level, points work until it says you are in a different city. We can not see city boundaries but OSM has thousands of city boundaries. The simple solution is if the neighborhood boundaries are clearly defined they belong in OSM as polygons. If neighborhood boundaries are not clearly defined then they should be represented by points. For the supporters of no admin boundaries in OSM, build the case on the mailing lists instead of just saying there is a growing support for no boundaries. In some parts of the US there is a growing support that climate change is a hoax. That doesn't make it true. Build a case for removing admin boundaries (and please include landuse.) Ideally in the future we can have a fuzzy boundary. But until then I think what I proposed is an acceptable solution. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Mapathons in San Diego and Chicago this Saturday
Hello, We are hosting a joint mapathon at the Red Cross offices in San Diego and Chicago next Saturday morning, March 28th: http://wiki.openstreetmap.org/w/images/0/06/San_Diego_and_Chicago_Mapathon_28MAR2015.pdf If you are interested in participating and helping new mappers, please get in touch with me. Thank you! Cristiano -- Cristiano Giovando Technical Project Manager Humanitarian OpenStreetMap Team cristiano.giova...@hotosm.org http://hot.openstreetmap.org ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
