Re: [Talk-us] [OSM-talk] Tagging Live indoor music venues
I would prefer amenity as it fits in better with other entertainment venues such as cinemas, theatres, concert halls and pubs. Leisure is more for sports places and swimming pools in my mind. Phil (trigpoint) -- Sent from my Nokia N9 On 25/02/2013 9:58 Floris Looijesteijn wrote: On Sun, Feb 24, 2013 at 6:59 PM, Philip Barnes p...@trigpoint.me.uk wrote: I would support amenity=music_venue, it describes this type of place. I looked at my local music_venue and it was tagged as leisure=music_venue Leisure seems to have slightly more (62) than amenity (56) at the moment. I don't really care which one is used but they're probably the same so we should choose one. http://taginfo.openstreetmap.org/tags/leisure=music_venue http://taginfo.openstreetmap.org/tags/leisure=music_venue Greets, Floris ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TopOSM 2
Looks very pretty, and I think this would be a great thing to have on the new US servers! One small styling thing... It's sometimes a bit hard to read the text. Could you replace the white halo with a black one, maybe? - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TopOSM 2
Agreed -- looks very nice. Thank you. It would be very useful, I think, to have a layer which presents the currently available USGS topomaps for two reasons: first, as a reference to illustrate improvements; second, as a reference to illustrate gaps. Also, I should know, but what is the origin of the elevation data to provide the hillshading? Thanks. --Ceyockey ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Wilderness Data
SteveA, I'm out of the country right now but can wait to get my hands on the data when I get back.( Internet is spotty everywhere I've stayed. ) I've been working on US National Parks on the wiki, see http://wiki.openstreetmap.org/wiki/WikiProject_US_National_Parks. My goal is to see all of the National Parks updated. I think it would be useful to link our wiki pages to help others find the data they need. I'd do it but with bad internet service it would have to wait until I'm back in the States. I also know the NPS is working with OSM. They would like to use our data, but feel constrained since they are required to publish as PD. They are working on a version of Potlatch that would update both their gis system as well as OSM. Thanks, Clifford On Sun, Feb 24, 2013 at 6:21 PM, stevea stevea...@softworkers.com wrote: A significant subset of the fresh data published on the aforementioned US Forest Service (USFS) site (National Forest and Wilderness boundaries, others are available) were successfully transformed from NAD83/shapefile to WGS84/.osm. (Thanks to all who made technical suggestions -- they worked!). Results from data at this site are nationwide. Both National Forest and Wilderness boundary sets yield huge files: each is hundreds of megabytes, unwieldy on most JOSM desktops. So, any US Contributor could do the same, then regionalize these data into smaller chunks: recommended both for JOSM performance reasons and to share the load among OSM community. If you wish to follow my ten step technical data transformation, which takes nationwide data sets (for forests, wilderness...) and successfully isolates single forests or wilderness areas while respecting multipolygon memberships, I am happy to send you my workflow. A wiki page tracks this effort: http://wiki.openstreetmap.org/** wiki/US_Forest_Service_Datahttp://wiki.openstreetmap.org/wiki/US_Forest_Service_Data. I encourage US Contributors to compare their local/current OSM state of National Forests and any contained Wilderness areas with these data, and to become aware of any OSM community that may be importing them. If so, offer a heads up that these new data are available -- and your thanks. If not, feel free to contribute these USFS data to OSM yourself! I am starting this in USFS Pacific Southwest Region 5, (California), a staggering 20 million acres (8 million hectares) of forest. My first case was with Los Padres National Forest, an area stretching nearly half the state, 48% of it containing ten distinct wilderness areas. The good news: this first seed is planted using these new USFS data, and mapnik/standard rendering is presently occurring. I now move on to Angeles, Cleveland and San Bernardino National Forests (and their wilderness area subsets), then I intend to complete Region 5's eastern and northern National Forests: 1 down, 3 to do now, 15 more to go: whew! Cheers, SteveA California __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging Live indoor music venues
On Sun, Feb 24, 2013 at 8:37 AM, william skora skorasau...@gmail.com wrote: Hi, I was curious us to hear what others have been using to tag music venues. There's numerous places in my city that hold upwards of 1,000 people for music concerts (also called 'shows'). In the US, they're indoors, serve alcohol, and usually only open when there are shows. There's usually admittance fees to enter. I'm thinking of places like House of Blues (yes, there's restaurants adjacent to some of them, but the one i've been to is separate from the concert venue), (Cleveland places like Beachland Ballroom, the Grog Shop), and more famous places like Bowery Ballroom. It seems like these would fall under amenity=theatre http://wiki.openstreetmap.org/wiki/Theatre. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Tagging Live indoor music venues
amenity=music_venue + music_venue=concert_hall/music_club/opera_house/? Now, how should restaurants that e.g. have live music every night (and host touring artists, too) be tagged? Should tags such as bar=yes or/and restaurant=yes be added where appropriate? Cheers, -Jaakko .. Who hasn't formed a solid opinion nor read all documentation on tagging multi-feature venues but who often adds bar/restaurant/atm/swimming_pool/etc=yes tag when they are available in a facility. Sent from my BlackBerry® device from Digicel -- Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta -Original Message- From: Martin Koppenhoefer dieterdre...@gmail.com Date: Mon, 25 Feb 2013 15:11:11 To: Floris Looijesteijno...@floris.nu Cc: OSM Talkt...@openstreetmap.org; talk-us@openstreetmap.org Subject: Re: [OSM-talk] [Talk-us] Tagging Live indoor music venues 2013/2/25 Floris Looijesteijn o...@floris.nu: On Sun, Feb 24, 2013 at 6:59 PM, Philip Barnes p...@trigpoint.me.uk wrote: I looked at my local music_venue and it was tagged as leisure=music_venue Leisure seems to have slightly more (62) than amenity (56) at the moment. which is both not really established ;-) I don't really care which one is used but they're probably the same so we should choose one. if they're the same I'd prefer amenity (as it's more neutral). Interestingly both variants are proposed on the same page since 2007: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_venue There is also this proposal for a venue that could have been of interest in this context, but is currently not used at all: http://wiki.openstreetmap.org/wiki/Proposed_features/Musicclub cheers, Martin ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging Live indoor music venues
JaggedMind jagged+...@cow.zotzed.net wrote: On Sun, Feb 24, 2013 at 8:37 AM, william skora skorasau...@gmail.com wrote: Hi, I was curious us to hear what others have been using to tag music venues. There's numerous places in my city that hold upwards of 1,000 people for music concerts (also called 'shows'). In the US, they're indoors, serve alcohol, and usually only open when there are shows. There's usually admittance fees to enter. I'm thinking of places like House of Blues (yes, there's restaurants adjacent to some of them, but the one i've been to is separate from the concert venue), (Cleveland places like Beachland Ballroom, the Grog Shop), and more famous places like Bowery Ballroom. It seems like these would fall under amenity=theatre http://wiki.openstreetmap.org/wiki/Theatre. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us The amenity=theatre tag would apply to some venues, but not all. In Nashville, TN, USA, where I live, a lot of restaurants and bars have live music on at least some evenings during the week. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Tagging Live indoor music venues
On Mon, 2013-02-25 at 14:37 +, Jaakko Helleranta.com wrote: amenity=music_venue + music_venue=concert_hall/music_club/opera_house/? Now, how should restaurants that e.g. have live music every night (and host touring artists, too) be tagged? The tag live_music has been used 9 times, where music isn't the primary purpose. amenity=pub live_music=yes or amenity=restaurant live_music=sun Phil (trigpoint) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TopOSM 2
I agree with the previous replies. It looks wonderful. The cartography is beautiful. Serge is right though, the blue text with the white halo for the water features is difficult to read. Sometimes it appears a little blurry. I am not sure a black halo will do the trick either. What about changing the color of the text; maybe making it a darker shade of blue? I love the hillshading. It makes the contours pop. And your project covers my old stomping grounds. Couldn't like it any better. Rick Marshall -- Rick Marshall, PhD, GISP President Vertical GeoSolutions, Inc (VerticalGeo) 130 Sawgrass Ln O'Fallon, IL 62269 (618) 670-4259 rick.marsh...@verticalgeo.com http://www.verticalgeo.com http://www.culturescapes.net Vertically Thinking Blog: http://verticalgeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Thu, Feb 21, 2013 at 9:04 PM, Brian May b...@mapwise.com wrote: On 2/21/2013 7:27 PM, Brian Cavagnolo wrote: Hey guys, In a previous thread on parcel data, some people expressed interest in participating in creating some sort of open repository for parcel data. I was imagining a conference call or something to discuss next steps, but I think we can advance with email. I'm imagining that it makes sense to separate the data gathering process from the data standardization/import process. Regarding the data gathering, the main objective is to gather recent raw data, licensing terms, and meta data from jurisdictions in whatever form they make it available, organize it in a dumb directory structure. I was just going to set up an FTP (read-write) and HTTP (read-only) server to get this going. Are there any recommendations/opinions on a longer-term approach here? Custom webapp? Off-the-shelf webapp? Somebody mentioned a git repository. Regarding standardization/import, I was planning on setting up an empty instance of the rails port as a test bed. Then participating users could point JOSM and other tools at this alternative rails port to examine, edit, and import parcel data. We could also provide planet-style dumps and mapnik tiles. The idea is that we would have a safe place to screw up and learn. Does this sound like a reasonable direction? Oh, and I found this fantastic paper that some parcel data people (Abt Associates, Fairview Industries, Smart Data Strategies) recently put together for HUD [1] that examines many of the issues that they faced building a parcel database. Timely. Ciao, Brian [1] http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Hi Brian, I am interested in collaborating on this. So here's some thoughts: From my perspective (and I think others as mentioned in other email threads), the main thrust of utilizing parcels is a source of addresses based on parcel centroids where address points or buildings with addresses are not available. In addition, several people have mentioned they utilize parcels as an overlay to assist with digitizing. The current consensus is that parcels should not be imported as a whole. The current _majority_ is that parcels should not be imported ;-) I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. We need to capture more information and a spreadsheet gets a bit unwieldy after so may columns. I've got a prototype that I am working on getting out in the wild soon, but basically its a web form that people register to use and the info sits in a database. I'm with you on this. I think we can get going with Ian's existing spreadsheet, but I think we're going to eventually want a longer form capability. There seems to be some open source open data portal options out there (e.g., https://github.com/azavea/Open-Data-Catalog/). Also, Nancy von Meyer, one of the authors of that paper I posted a link to, (and as you mentioned, a long time advocate for a national parcel database) advised me of this inventory of parcel data that she and others have built up: http://www.bhgis.org/inventory/ ...of course it's read-only. But it's a good resource to browse around. And we could probably arrange more back-end access. A by-product of the effort to identify, catalog, gather raw data, etc. would be having a central location for storing raw parcel data that is not readily downloadable. For example, someone happens to have a copy of X county parcel data that they had to send a check for $25 to acquire, they received it on CD, and they would like to donate it to a central repository. This is assuming there are no restrictions on the data. It sounds like you're willing and able to donate disk and bandwidth to support this effort. I don't see a need to make a copy of data that is already sitting on the web. Good point about not duplicating the data that is readily available on the web. But one thing I've run into in the few cases that I've investigated is that explicit terms are often unavailable on those websites. So some outreach is required to confirm the terms before redistributing the data. And of course policies can change. So there's something to be said for saving off a copy of some data to a place where it is clearly guaranteed to be OSM compatible. As far as standardization/import and the rails server - I think this is not the right path to take. As mentioned above, we shouldn't be wholesale importing parcels. Now you could do some standardization of parcel data for example to render polygons by land use codes and show single family, multi-family, commercial, government, etc land use types as an overlay layer for
Re: [Talk-us] parcel data next steps
Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid. Steve PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo bcavagn...@gmail.com wrote: On Thu, Feb 21, 2013 at 9:04 PM, Brian May b...@mapwise.com wrote: On 2/21/2013 7:27 PM, Brian Cavagnolo wrote: Hey guys, In a previous thread on parcel data, some people expressed interest in participating in creating some sort of open repository for parcel data. I was imagining a conference call or something to discuss next steps, but I think we can advance with email. I'm imagining that it makes sense to separate the data gathering process from the data standardization/import process. Regarding the data gathering, the main objective is to gather recent raw data, licensing terms, and meta data from jurisdictions in whatever form they make it available, organize it in a dumb directory structure. I was just going to set up an FTP (read-write) and HTTP (read-only) server to get this going. Are there any recommendations/opinions on a longer-term approach here? Custom webapp? Off-the-shelf webapp? Somebody mentioned a git repository. Regarding standardization/import, I was planning on setting up an empty instance of the rails port as a test bed. Then participating users could point JOSM and other tools at this alternative rails port to examine, edit, and import parcel data. We could also provide planet-style dumps and mapnik tiles. The idea is that we would have a safe place to screw up and learn. Does this sound like a reasonable direction? Oh, and I found this fantastic paper that some parcel data people (Abt Associates, Fairview Industries, Smart Data Strategies) recently put together for HUD [1] that examines many of the issues that they faced building a parcel database. Timely. Ciao, Brian [1] http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Hi Brian, I am interested in collaborating on this. So here's some thoughts: From my perspective (and I think others as mentioned in other email threads), the main thrust of utilizing parcels is a source of addresses based on parcel centroids where address points or buildings with addresses are not available. In addition, several people have mentioned they utilize parcels as an overlay to assist with digitizing. The current consensus is that parcels should not be imported as a whole. The current _majority_ is that parcels should not be imported ;-) I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. We need to capture more information and a spreadsheet gets a bit unwieldy after so may columns. I've got a prototype that I am working on getting out in the wild soon, but basically its a web form that people register to use and the info sits in a database. I'm with you on this. I think we can get going with Ian's existing spreadsheet, but I think we're going to eventually want a longer form capability. There seems to be some open source open data portal options out there (e.g., https://github.com/azavea/Open-Data-Catalog/). Also, Nancy von Meyer, one of the authors of that paper I posted a link to, (and as you mentioned, a long time advocate for a national parcel database) advised me of this inventory of parcel data that she and others have built up: http://www.bhgis.org/inventory/ ...of course it's read-only. But it's a good resource to browse around. And we could probably arrange more back-end access. A by-product of the effort to identify, catalog, gather raw data, etc. would be having a central location for storing raw parcel data that is not readily downloadable. For example, someone happens to have a copy of X county parcel data that they had to send a check for $25 to acquire, they received it on CD, and they would like to donate it to a central repository. This is assuming there are no restrictions on the data. It sounds like you're willing and able to donate disk and bandwidth to support this effort. I don't see a need to make a copy of data that is already sitting on the web. Good point about not duplicating the data that is readily available on the web. But one thing I've run into in the few cases that I've investigated is that explicit terms are often unavailable on those websites. So some outreach is required to confirm the terms before redistributing the data. And of course policies can change. So there's something to be said for saving off a copy of some data to a place where it is clearly guaranteed to be OSM
Re: [Talk-us] parcel data next steps
On Mon, Feb 25, 2013 at 3:39 PM, SteveCoast st...@asklater.com wrote: Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid. If you haven't done so already, please try editing an area that has had parcel data added. It is a nightmare. I know tools can be improved, but still parcels have very little relation to any other feature, even landuses, fences, etc. often don't line up. The only way I'd like to see parcel data added to OSM is if the concept of layers is added to the API. Then we'd have a landuse layer, a parcel layer, a ??? layer, and an everything else layer. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TopOSM 2
On 02/25/2013 03:06 PM, Rick Marshall wrote: Serge is right though, the blue text with the white halo for the water features is difficult to read. Sometimes it appears a little blurry. I am not sure a black halo will do the trick either. What about changing the color of the text; maybe making it a darker shade of blue? I completely agree. This is far from the finished map and it needs a lot more work. In addition to hard-to-read labels and layering issues, there are many basic features still missing from the map. Most importantly, the demo uses all pre-rendered tiles. That works for a small area like this, but becomes impractical for a nationwide map. The biggest challenge may be to get acceptable rendering performance so that tiles can be rendered as they are requested. Nevertheless, I'm hopeful it can be done without too many compromises. - Lars ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
I'm not arguing that life is easy with parcels. I'm questioning the majority statement. If anything parcels will be hard. That's a good thing. If we want to take the easy route we should give up now. Steve PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster On Feb 25, 2013, at 12:50 PM, Josh Doe j...@joshdoe.com wrote: On Mon, Feb 25, 2013 at 3:39 PM, SteveCoast st...@asklater.com wrote: Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid. If you haven't done so already, please try editing an area that has had parcel data added. It is a nightmare. I know tools can be improved, but still parcels have very little relation to any other feature, even landuses, fences, etc. often don't line up. The only way I'd like to see parcel data added to OSM is if the concept of layers is added to the API. Then we'd have a landuse layer, a parcel layer, a ??? layer, and an everything else layer. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Virtual Mappy Hour starting in 30 minutes
Quick reminder that this week's Virtual Mappy Hour is starting in 30 minutes. Elliott Pack will talk about mapping bus routes in Baltimore. Swing by! http://www.openstreetmap.us/2013/02/february-25-virtual-mappy-hour-bus-route-mapping/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Virtual Mappy Hour starting in 30 minutes
We're starting now! Join us: https://plus.google.com/hangouts/_/bee610ba18046d4ea90d36eb005ef1e2037c0257?authuser=0hl=en On Mon, Feb 25, 2013 at 7:59 PM, Alex Barth a...@mapbox.com wrote: Quick reminder that this week's Virtual Mappy Hour is starting in 30 minutes. Elliott Pack will talk about mapping bus routes in Baltimore. Swing by! http://www.openstreetmap.us/2013/02/february-25-virtual-mappy-hour-bus-route-mapping/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Virtual Mappy Hour starting in 30 minutes
Also on Youtube right now: http://www.youtube.com/embed/0vgIIdiWOpk On Mon, Feb 25, 2013 at 8:30 PM, Alex Barth a...@mapbox.com wrote: We're starting now! Join us: https://plus.google.com/hangouts/_/bee610ba18046d4ea90d36eb005ef1e2037c0257?authuser=0hl=en On Mon, Feb 25, 2013 at 7:59 PM, Alex Barth a...@mapbox.com wrote: Quick reminder that this week's Virtual Mappy Hour is starting in 30 minutes. Elliott Pack will talk about mapping bus routes in Baltimore. Swing by! http://www.openstreetmap.us/2013/02/february-25-virtual-mappy-hour-bus-route-mapping/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OSM US Server Infrastructure
Hi, Just a thought on US tag info server, It might be better to just work on a patch to the existing tag info code/server to support regions directly. Having our own taginfo server is not that useful if it is not integrated into the main wiki. The wiki is the major entryway to the tag info server, without the main wiki integration It will probably not get used that much. Setting it up will certainly not do any harm, just presenting an alternate path before somebody goes through the work in setting it up. Thanks Jason On Sat, Feb 23, 2013 at 10:57 AM, Paul Norman penor...@mac.com wrote: A us-only taginfo. Frequently the tag usage distribution varies between regions which is why there local taginfo instances for a few countries (http://wiki.openstreetmap.org/wiki/Taginfo/Sites) The taginfo sqlite databases total about 4GB for the planet so this shouldn’t take much space, but I’m not sure how much CPU and disk is involved in creating the db. From: Ian Dees [mailto:ian.d...@gmail.com] Sent: Saturday, February 16, 2013 1:23 PM To: talk-us@openstreetmap.org Openstreetmap Subject: [Talk-us] OSM US Server Infrastructure Hi talk-us! I'm putting together a request to upgrade the OSM US server infrastructure and would love to have the community's feedback. To learn more about what sort of resources the OSM US chapter currently has to offer, check out the wiki page I put together: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers In general, though, we have a primary machine with lots of memory and a fair amount of disk. This hardware is currently used to serve imagery tiles proxied from various sources and rendered from various Mapnik stylesheets. There's also an osm2pgsql database that is kept up to date on an hourly basis. Are you working on a project related to OSM and need resources to keep it going? Do you have an idea for improving OSM in the US but don't know how to proceed? Let me know and we can discuss what sort of hardware might be needed. -Ian ___ 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] new mapper tutorial explaining overlapping Ways?
Hmm... this cover at least part of what you want? http://www.youtube.com/watch?v=5rnBHhD3HUs This is probably too basic http://wiki.openstreetmap.org/wiki/Potlatch_2/Primer Else try http://wiki.openstreetmap.org/wiki/Video_tutorials also some of the youtube videos http://www.youtube.com/watch?v=P8qKaL9IGjk On Sun, Feb 24, 2013 at 1:51 PM, Peter Dobratz pe...@dobratz.us wrote: I'm trying to help along a newer local mapper, and I'm looking for any good tutorials or references to help show how to create Ways without overlapping/self-intersecting. http://www.openstreetmap.org/browse/way/206875817 These are the kind of things that MapRoulette picks up and other users fix, but it would be helpful to not create them in the first place. Maybe it's just as simple as oh yeah, you have to double-click to end a Way in P2, not just retrace back to the beginning point. Peter ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Virtual Mappy Hour starting in 30 minutes
On 2/25/2013 8:30 PM, Alex Barth wrote: Elliott Pack will talk about mapping bus routes in Baltimore. Swing by! Great presentation; I couldn't manage to get my video chat working, but have one comment. Re: Bus Route relations way members and the negative recommendation in the Wiki that role 'forward', 'backward', and 'alternate' no longer be used: One case they are useful is where the transport map indicates travel direction. Bidirectional travel is shown by a solid line, and a single travel direction is shown with embedded arrows, as in this example: http://tile.memomaps.de/?zoom=17lat=34.84947lon=-82.39806layers=TBTTT I could not find the recommendation not to use the roles in the Wiki. http://wiki.openstreetmap.org/wiki/Relation:route Of course, the routes are still shown as solid lines if no roles are used. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Mon, Feb 25, 2013 at 12:39 PM, SteveCoast st...@asklater.com wrote: Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid. Fair enough. I'll downgrade my statement from majority to concerns have been expressed. Ciao, Brian On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo bcavagn...@gmail.com wrote: On Thu, Feb 21, 2013 at 9:04 PM, Brian May b...@mapwise.com wrote: On 2/21/2013 7:27 PM, Brian Cavagnolo wrote: Hey guys, In a previous thread on parcel data, some people expressed interest in participating in creating some sort of open repository for parcel data. I was imagining a conference call or something to discuss next steps, but I think we can advance with email. I'm imagining that it makes sense to separate the data gathering process from the data standardization/import process. Regarding the data gathering, the main objective is to gather recent raw data, licensing terms, and meta data from jurisdictions in whatever form they make it available, organize it in a dumb directory structure. I was just going to set up an FTP (read-write) and HTTP (read-only) server to get this going. Are there any recommendations/opinions on a longer-term approach here? Custom webapp? Off-the-shelf webapp? Somebody mentioned a git repository. Regarding standardization/import, I was planning on setting up an empty instance of the rails port as a test bed. Then participating users could point JOSM and other tools at this alternative rails port to examine, edit, and import parcel data. We could also provide planet-style dumps and mapnik tiles. The idea is that we would have a safe place to screw up and learn. Does this sound like a reasonable direction? Oh, and I found this fantastic paper that some parcel data people (Abt Associates, Fairview Industries, Smart Data Strategies) recently put together for HUD [1] that examines many of the issues that they faced building a parcel database. Timely. Ciao, Brian [1] http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Hi Brian, I am interested in collaborating on this. So here's some thoughts: From my perspective (and I think others as mentioned in other email threads), the main thrust of utilizing parcels is a source of addresses based on parcel centroids where address points or buildings with addresses are not available. In addition, several people have mentioned they utilize parcels as an overlay to assist with digitizing. The current consensus is that parcels should not be imported as a whole. The current _majority_ is that parcels should not be imported ;-) I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. We need to capture more information and a spreadsheet gets a bit unwieldy after so may columns. I've got a prototype that I am working on getting out in the wild soon, but basically its a web form that people register to use and the info sits in a database. I'm with you on this. I think we can get going with Ian's existing spreadsheet, but I think we're going to eventually want a longer form capability. There seems to be some open source open data portal options out there (e.g., https://github.com/azavea/Open-Data-Catalog/). Also, Nancy von Meyer, one of the authors of that paper I posted a link to, (and as you mentioned, a long time advocate for a national parcel database) advised me of this inventory of parcel data that she and others have built up: http://www.bhgis.org/inventory/ ...of course it's read-only. But it's a good resource to browse around. And we could probably arrange more back-end access. A by-product of the effort to identify, catalog, gather raw data, etc. would be having a central location for storing raw parcel data that is not readily downloadable. For example, someone happens to have a copy of X county parcel data that they had to send a check for $25 to acquire, they received it on CD, and they would like to donate it to a central repository. This is assuming there are no restrictions on the data. It sounds like you're willing and able to donate disk and bandwidth to support this effort. I don't see a need to make a copy of data that is already sitting on the web. Good point about not duplicating the data that is readily available on the web. But one thing I've run into in the few cases that I've investigated is that explicit terms are often unavailable on those websites. So some outreach is required to confirm the terms before redistributing the data. And of course policies can change. So there's
Re: [Talk-us] parcel data next steps
Thanks Brian. I hear the point of view, I just don't want it to be (too) overstated. Steve PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster On Feb 25, 2013, at 8:41 PM, Brian Cavagnolo bcavagn...@gmail.com wrote: On Mon, Feb 25, 2013 at 12:39 PM, SteveCoast st...@asklater.com wrote: Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid. Fair enough. I'll downgrade my statement from majority to concerns have been expressed. Ciao, Brian On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo bcavagn...@gmail.com wrote: On Thu, Feb 21, 2013 at 9:04 PM, Brian May b...@mapwise.com wrote: On 2/21/2013 7:27 PM, Brian Cavagnolo wrote: Hey guys, In a previous thread on parcel data, some people expressed interest in participating in creating some sort of open repository for parcel data. I was imagining a conference call or something to discuss next steps, but I think we can advance with email. I'm imagining that it makes sense to separate the data gathering process from the data standardization/import process. Regarding the data gathering, the main objective is to gather recent raw data, licensing terms, and meta data from jurisdictions in whatever form they make it available, organize it in a dumb directory structure. I was just going to set up an FTP (read-write) and HTTP (read-only) server to get this going. Are there any recommendations/opinions on a longer-term approach here? Custom webapp? Off-the-shelf webapp? Somebody mentioned a git repository. Regarding standardization/import, I was planning on setting up an empty instance of the rails port as a test bed. Then participating users could point JOSM and other tools at this alternative rails port to examine, edit, and import parcel data. We could also provide planet-style dumps and mapnik tiles. The idea is that we would have a safe place to screw up and learn. Does this sound like a reasonable direction? Oh, and I found this fantastic paper that some parcel data people (Abt Associates, Fairview Industries, Smart Data Strategies) recently put together for HUD [1] that examines many of the issues that they faced building a parcel database. Timely. Ciao, Brian [1] http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Hi Brian, I am interested in collaborating on this. So here's some thoughts: From my perspective (and I think others as mentioned in other email threads), the main thrust of utilizing parcels is a source of addresses based on parcel centroids where address points or buildings with addresses are not available. In addition, several people have mentioned they utilize parcels as an overlay to assist with digitizing. The current consensus is that parcels should not be imported as a whole. The current _majority_ is that parcels should not be imported ;-) I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. We need to capture more information and a spreadsheet gets a bit unwieldy after so may columns. I've got a prototype that I am working on getting out in the wild soon, but basically its a web form that people register to use and the info sits in a database. I'm with you on this. I think we can get going with Ian's existing spreadsheet, but I think we're going to eventually want a longer form capability. There seems to be some open source open data portal options out there (e.g., https://github.com/azavea/Open-Data-Catalog/). Also, Nancy von Meyer, one of the authors of that paper I posted a link to, (and as you mentioned, a long time advocate for a national parcel database) advised me of this inventory of parcel data that she and others have built up: http://www.bhgis.org/inventory/ ...of course it's read-only. But it's a good resource to browse around. And we could probably arrange more back-end access. A by-product of the effort to identify, catalog, gather raw data, etc. would be having a central location for storing raw parcel data that is not readily downloadable. For example, someone happens to have a copy of X county parcel data that they had to send a check for $25 to acquire, they received it on CD, and they would like to donate it to a central repository. This is assuming there are no restrictions on the data. It sounds like you're willing and able to donate disk and bandwidth to support this effort. I don't see a need to make a copy of data that is already sitting on the web. Good
Re: [Talk-us] parcel data next steps
SteveCoast writes: If anything parcels will be hard. That's a good thing. If we want to take the easy route we should give up now. Well, as Josh points out, parcels are not necessarily related to anything on the ground. They could be, e.g. my property lines are co-incident with stone walls, barbed wire, and split-rail fences except where they don't. And the source of parcel data is going to be external to OSM -- almost certainly the county clerks's real property office. And it's not a physical description of the property anyway -- it's a legal description of it. Having the physical features perfectlty mapped wouldn't help. So the chief value, I think, of getting this into OSM is more, rather, getting it into OSM format, and aggregating it on a single server. That is an fton of value, and is a worthy goal. I don't believe that there's any sensible or valuable way to get it into OSM itself. I only say this because I tried it. Bought a copy of Oneida County's parcel data, put it into OSM format. Loaded it into JOSM, and ... It didn't really make any sense when merged in with OSM data. As a separate layer, it makes sense. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
