Re: [OSM-talk] Abandoned Rails
The OSM community is what OSM is even more than it is a map. People that are passionate about railways are a part of that community and they do contribute a lot, especially in the US where we don't have as many mappers. They pour lots of time and love and passion into their efforts. I don't think a policy of deleting that work just because what they're mapping isn't immediately visible on the ground is a good way of building and strengthening our community. In fact, as it is easy to see in this thread, its actively doing the opposite. And community is what makes OSM. I'd therefor like to propose that abandoned railways be treated like borders. Even if you can't see it along a given stretch there are people who can and they have put a huge amount of effort into that work. Lets respect that and strengthen the community rather than deleting it and doing the opposite. Cheers, Greg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Importing parks and schools for Anne Arundel County MD
Hi Eric, It looks like a good start to me. There were a couple of things that stuck out to me: many of the parks and schools are already in OSM, even if just as a GNIS point. Also, many of the curves in the import are over digitized. We don't need curves of that size to have that many points. The dataset isn't very large which makes it much easier to manage. I don't know how you planned on doing the import but below is my suggestion for how to go about it. I wouldn't import the data per say, as in uploading the .osm file you have. I would download the current OSM data for the area covered. Then, in the import file I would check each polygon, one at a time, for duplicates and boundaries that are overdigitized for OSM. If the polygon needs to be simplified, JOSM has a simplify way tool (Shift + Y) that does the job handily. If the park or school is already in OSM I would use my judgement. If it was put in manually by another mapper I would leave it alone. If it is a GNIS point, delete the GNIS point, since your data is better than the GNIS points from what I can see. Then, copy it over from the import layer to the OSM layer, and delete if from the import layer. That way the import layer only has the polygons you haven't imported yet so you can easily keep track of things if it takes a few sessions to finish. This method makes sure that everything is at least looked at before its added which results in things being much more sane. It also allows you to add address data to the schools or trace courts and playing fields in the parks if you feel like doing so, although its definitely not necessary. I've used the above method for importing school and park polygons in a couple of small areas before and it worked wonderfully. The only other thing that stuck out to me about the data was the B A trail. You have a polygon for the trail which is awesome but I would also add in a properly tagged linear way. It will make it possible for routers to use it as well as rendering properly. Good luck! Cheers, Greg On Thu, May 29, 2014 at 7:12 PM, Eric H. Christensen e...@christensenplace.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Dec 12, 2013 at 05:17:59PM -0800, Paul Norman wrote: You'll need to develop a translation for the shapefiles that converts shapefile attributes to OSM tags, for use with ogr2osm or shp2osm.jar. This is moderately technical. I used JOSM to import the shapefiles and turn them into .osm files. I went through and removed attributes that didn't make sense (which would be almost all of them) and added ones that did. Everything appears to have a name and is either a school or a park (and contains appropriate attributes for that). When you've done that, post the .osm file somewhere and send a link to the imports@ list for review. I ended up splitting the data into two files. The first[0] contains simple polygons that outline the plots of land and was somewhat easy to get fixed. The second[1] contains all the multi-polygon shapes that I didn't want to deal with just yet. There are only a handful of these areas so I'm not overly worried about them just yet. Everything is sitting up on github[2] at the moment and are available for anyone to take a look at. I'd appreciate feedback on this. [0] https://raw.githubusercontent.com/mappingdc/Anne-Arundel-imports/master/AA_parks.osm [1] https://raw.githubusercontent.com/mappingdc/Anne-Arundel-imports/master/AA_parks_multipolygons.osm [2] https://github.com/mappingdc/Anne-Arundel-imports Thanks! - --Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTh+jvAAoJEB/kgVGp2CYvX3UL/3qbsCRXZKwQkHifSIl5PMis r9UKhLaGxnOWZtfPExzWMdQ4cCtKbqoW9yqU6tlJ8eYBmnjuwG1Yc+kTHVOL4unt Q+9/7tJpp921e2hhIQiqODV7QAlPncgYuD9KBUVt8cG5sW3cFi8pNmg75UYg/O55 Mm3ZzX2rTl+mIq5kJU7ddpu7jb7vNqZMrwyYYSbDRhqzJI/lYNyDKJxLpDHAwJ7/ RIENJQhoCoaaYWk5DTr0TZIvYJAGGBX6P0La45YimzvsO1k0ud/BkeRYYeTKvyeP hGCmpl3d02kSHf8+7tKlJj7BLU/80Cwkrp9dHWsGswczzupJLr1MjO5Vub7WsN8a lVvGoQp0JMeGsCddzrw/C6cAQg+/sM1LD2wyl8jSxB+6bMdwuqllxrrKq8mCGpPi Jddu9eKUKQu8ClarScEsKEIdi9Q9+7QhN6LmRo4DJ0EznaljQdV8sUfV8cRFoSrG 3+x/mjZZREO3MbaYK/SxN7I3Urbq9fafzCh2MRN/6A== =lFBs -END PGP SIGNATURE- ___ 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: [OSM-talk] Import of buildings in Chicago
This is Yet Another import from a database being maintained by someone else. This is why we need a closedstreetmap.org, which publishes, in OSM format using the OSM API, data which cannot be sensibly edited. I disagree that buildings can't be sensibly edited. I trace them, add addresses to them, give them tags such as school or hospital or restaurant or fire station or library or Sometimes I even delete them if they're not there anymore. Same as streets, or parks, really. Also, I know in San Francisco some people were experimenting with adding more information to buildings such as number of units and construction materials, to make the data more useful for emergency response. (eg, after a large earthquake, maybe we should check the unreinforced masonry buildings with a lot of units first) I also don't see the problem with importing a dataset that someone else is still maintaining. We're just forking their dataset. Pretty much every municipality has a database of their streets...so do we. If they have one of their buildings, why can't we? In the Dutch community we've been discussing this a while ago, because all buildings in the Netherlands are available in a high quality PD dataset, called BAG (Basisregistratie Adressen and Gebouwen: base registration of adresses and buildings). Ironically, exactly the reason this dataset is existing and freely available, it makes it not worth while the effort to import this into OSM, and impose the burden of updating it onto ourselves. It is much more convenient to take OSM without buildings (and addresses) and merge this with the other dataset. I disagree that it would be more convenient to have to merge two different datasets, that are probably in different formats, than it would be to just use one dataset that has all the information in it. Especially seeing as how everyone who wants to use the data will have to do that work, where as if it is in OSM it only has to be merged that one time. If that data were in OSM then all the apps and routers and maps that use OSM, and there are a ton of them, would be able to locate addresses and render buildings. As it is they aren't able to because the data isn't there and each application or map would have to find the data for the Netherlands (and if we do things that way everywhere else, the data for everywhere else, too!) and then figure out how to merge it or how to work with a non-OSM format. More likely this doesn't happen and everybody ends up with much less useful data. Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Fresno castradal imports
I think that this import was poorly done but overall I don't see the problem with having this type of data in OSM. In fact, I think it is really useful and don't entirely understand the backlash against it. I would really enjoy having that kind of base to work with. So, Thoughts on Plot and Building data in OSM. A. Great for rendering. (Generaly this is probably why all these imports happen the way they do.) 1. The way Mapnik displays landuse data as different colors allows renders to display useful and interesting information visually at a very fine grained way. 2. Some maps render the plots directly and it can look very nice. For instance, Google Maps renders the parts of San Francisco this way with the plots as very faint lines. It looks great and conveys more information. i. Yes, this could be done by rendering OSM and then rendering the plot data separately. This could, however, be said of everything in OSM. The OSM model isn't everything in a separate layer, it is everything altogether. What makes plots unique in this regard? Why do we want them separate? B. Editing. (I think the problems here are part of the reason for the hostility towards imports, especially ones of this type) 1. Building and plot information greatly decreases the download area because of the 50K object limit. Some people like to do edits over large areas and this makes that difficult. For instance, in this thread someone mentioned they have 68000 square kilometers they want to work on. I edit almost exclusively in a city that is ~120- square kilometers of land. I don't think we're going to get a whole lot of consensus on how dense the data should be with these types of differing use patterns. I would look at having all the building outlines as a godsend while others look at it as a problem because they can't download an entire area as easily. Personally I take this as an indication that our tool chain really needs more work. The 50K object limit is what is getting in the way of mappers with this problem, not the data itself. Even in San Francisco where, other than the streets and some GNIS nodes, there really hasn't been any imports this limit gets in the way. How do mappers in places with really dense non-imported data deal with this issue? 2. Dense building and plot information greatly increases the file size that editors have to cope with and many of them can't, especially for large areas. Again, I don't think a consensus is going to be easy to find here. I want dense data, building outlines and plots. I think that is useful for many purposes. Others aren't interested in this type of data and find it nothing but a nuisance. Again, maybe better tools will help but I think we're more likely to see this type of data multiply rather than disappear. 3. This one is more subjective but the first thing I thought when I zoomed in on the Fresno data was awesome. I get the impression other people (most?) think eww, what a mess! I would enjoy that kind of base to work with and expand on even if imperfect. Building outlines would be better but plot information would be great, too. Mostly it would just be so much easier to tag a pre-existing area instead of having to trace one from scratch every single time you want to add a park, or school, or fire station etc to the map. If the area didn't look right, edit it. I think people look too much into the plot data being official and owned by someone else. Once its in OSM its ours and we own it. This import does have its problems but whats the rush to delete it? Without imported data Fresno would pretty much just be a white place on the map. The streets are all tiger import, many of the POIs are from the GNIS import and almost all of the rest of the data is from this one and little of any of it has seen much editing. Are we really making a more useful set of geodata by cleaning out the plot info here? Cheers, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, etc. Points or outlines
If there is a point and an area I keep the area and delete the point. If the point has data I'd like to keep, as is often the case when I trace a park on the map and want to use the name and other info from a GNIS point I simply copy the attributes over. To easily copy the attributes over in JOSM I select the point, control+c to copy, select the way, and then control+shift+v copies in the attributes. I think I used to do this in Potlatch but that might have been the old one. If you don't feel like doing that and the area features are already drawn and already have names and type attributes, feel free to just delete the GNIS point. Other than elevation there usually isn't anything else that is particularly interesting in there. Cheers, Greg On Tue, Apr 24, 2012 at 11:38 AM, Josh Doe j...@joshdoe.com wrote: On Tue, Apr 24, 2012 at 1:21 PM, Charlotte Wolter techl...@techlady.com wrote: Hi all, In doing the remap in LA, I've run across parks, some schools and other map features that are marked with both points and outlines. For La Cienega Park, the park is outlined, coded park and named. There also is a point for La Cienega Park. My initial impulse was to delete the point, because the outline captured so much more information, but I thought I would ask first. Yes, there should be only one feature for each real world object, and the way/multipolygon has more spatial information, however the nodes might have other useful information like the GNIS feature ID. The best process is to copy/merge tags and relation memberships from the node to the area. If you use JOSM, the utilsplugin2 plugin has a Replace Geometry command which does all this for you in one step (simply select the node and the way, then press Ctrl+Shift+G). Read the wiki [1] for more details. If you use Potlatch2, this is much more time consuming. -Josh [1]: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Replace_Geometry ___ 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] tiff, dwg and nad83
Hi, Imported data turns down potential new mappers. I really disagree with this statement. I think the mappers would be turned off if we didn't import it when available. So you have all 250,000 address points for the city but instead of using them you'd rather us go collect all of them a second time?!? Nobody is going to do that. Same with building outlines. It might be true for some data but I think its a largely inaccurate statement. There have also been some really well done imports such as the MassGIS one in MA. Not using that data isn't going to get us any further than using it. It makes our data much more useful, so it gets used, which brings in more contributors which Maybe it would be different if there were no open data to import at all, then people would be more motivated to gather it so it would exist. However, if it does exist, weather or not we use it, that motivation is no longer there. I also think that in the US if government agencies are updating their data that we can use that we should look at that as part of the community. They're producing free data and so are weI just wish they could use our data they way we use theirs. -Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] importing bus stops
Anyone here with experience importing bus stops? Any particular considerations? I haven't imported any but I've tagged a bazillion of them. To make it more concrete, I have permission to import all UTA stops. They come in a shapefile similar to the one available for download here: http://gis.utah.gov/sgid-**vector-download/utah-sgid-** vector-gis-data-layer-**download-index?fc=BusStops_UTAhttp://gis.utah.gov/sgid-vector-download/utah-sgid-vector-gis-data-layer-download-index?fc=BusStops_UTA (That particular set of files is out of date, though) There's a number of properties that would map to OSM nodes pretty nicely: MAILBOX - create a separate node amenity= LIGHT - lit=yes SHELTER - shelter=yes BENCH - bench=yes (?) I looked at the shapefiles you linked to and didn't see any mailbox properties. I'd be wary of using an attribute like that to add mailbox nodes. How do you tell the location of the box relative to the stop unless they make sure they're very close before they mark that attribute that yes. Also, the file I looked at (SLC) only had null value for shelter and bench. Do the updated ones actually have some values there. Do you know what UTA is referring to in the CURB and GUTTER attributes? Again, the file I looked at only had zeros there. I always add shelter and bench information to the stops I tag. I also use a tag called ticker=yes/no to indicate if it has real time arrival data or not. So, lit, shelter and bench are all good tags to have if the data is there. How accurate is the coordinate data for those stop nodes? Is it good enough to indicate which corner the stop is at at an intersection, and which side of the corner? If it is that accurate awesome, if not the import just got a lot, lot harder to do correctly. Given all the info in the attributes for the stops (eg, direction and midblock etc) you could probably still make it work but not easily. If its really accurate though its good. Do you know if the location ID is publicly visible or only for backend purposes? In some places the stops have stop IDs that can be texted to 511 to get arrival times for the next bus or two. If these are public facing numbers I would throw them in a ref tag otherwise I would probably leave them out. I was planning to just use what I know which is highway=bus_stop for the bus stops, and railway=tram_stop for the light rail stops. But now I see that using highway=bus_stop is *very controversial*[1]! If it weren't so blatantly untrue I'd think it was a joke. Or did I miss something? To get back on topic, if anyone wants to help out devise a mapping from UTA stops file to OSM, I'd welcome some help. I've never done a local import before, and I'm not a particularly big fan of imports, so I want to proceed with caution. I use highway=bus_stop for all of my bus_stop tagging. As far as I know thats also how the public transit add on in JOSM handles them. The whole public_transport tag set feels like overkill to me. I don't see how having the bus stop node where the bus stop is as opposed to the on way is that hard to handle. Ideally the bus stops end up as part of route relations that make that explicit anyhow. -Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import
Yes, I see a lot of water features that are just not corroborated by the aerial imagery, which could mean one of at least three things: 1) The aerial imagery is out of date 2) The NHD data is out of date 3) The NHD data represents something I don't understand (the future, a temporary situation (which should not be in OSM), something underground?) Some of the water features in NHD are also seasonal, although that is usually tagged in the data. Also irrigation canals are often just ditches and can be hard to identify from aerial imagery especially the smaller ones as they aren't always in use. The tags on a lot of those features have some gnis:type tags that say ditch-canal or something like that but the OSM tag is just canal which doesn't really do a great job describing the situation exactly. I agree, though, the data you pointed out looks pretty odd, especially the square shapes. I'm surprised that NHD has data that includes irrigation ditches as small as some of the ones noted above. Anybody know how they gathered all of that data? Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OSM US Chapter elections and
Another barrage of questions The wiki says that the 2011-2012 election is coming up soon. How is this being organized and when is it actually going to be? The system that was set up last year worked pretty well. I think it was surveymonkey run by some independent (Apache?) observers. Is it possible to do this again? If so, what needs to be done? I know that at one point getting 503(c) status was a goal of the organization. Did this ever happen, and if not, what needs to be done? One thing I would like to see with the US servers is one set up to make extracts, especially for major cities and metro regions. Even the state ones can be rather unwieldy. Assuming others think this would be useful how do we go about setting something like this up? And last but not least has anyone started thinking about the next SOTM-US.? If the main SOTM is going to be in the August-September timeframe it might be a good idea to try and offset ours. For instance, aim for March so they aren't taking place one directly after the other. I threw this idea around some at SOTM Denver and it was well recieved but If we want to do this we'll need to get started planning it pretty soon. Same criteriahttp://wiki.openstreetmap.org/wiki/State_Of_The_Map_U.S._2010/BIDS/CRITERIAas last time? Cheers, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Pre SOTM gathering
Are there any pre-SOTM gatherings going on this evening? Or failing that can anybody recommend a brewery to get one going at? Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Announcing the DC Sidewalks Project
Thats really awesome work Serge. Not just a good idea but well implemented. Really slick. Thanks for your hard work. Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] address parsing by nominatim
It sounds like the current set of tags and structures in OSM don't properly support what you're trying to do at the moment. I think the best way to deal with it would to propose some new tags so that these type of addressing schemes can be properly supported in OSM with supporting documentation. It sounds like you need some sort of block or sector tag you could set on areas to define them properly. A couple of other tags for addressing like addr:block and addr:sector could then be added. It would definitely take some time before they get supported by the renderers and routers but I think that since a good sized chunk of the world uses these types of addressing systems we should have an explicit way to deal with them instead of trying to shoehorn them into a more European system. It will make it easier for mappers there to do things properly and probably also make things work more reliably. I don't have the experience with this type addressing to feel comfortable doing any of that but if you put something up on the wiki people can use and work on it. Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
On 12/14/2010 07:56 AM, Michał Borsuk wrote: I already told you twice to behave, you little shit. If it continues, I will have you removed from the list. That type of language and attitude is completely inappropriate. If someone needs to be removed from the list there a much better ways of handling it. --Greg ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [OSM-legal-talk] Is this click through agreement compatible with OSM?
On Mon, Dec 13, 2010 at 12:08 AM, Steve Bennett stevag...@gmail.com wrote: On Mon, Dec 13, 2010 at 6:56 PM, Gregory Arenius greg...@arenius.com wrote: I read this as saying that the terms of use, which are there as a hold harmless waiver, don't grant any rights. It specifically states that if the city is claiming copyright on the data it will do so in the file or on the website that the file is accessed from. The file in question has no such claims. Ok, well argued. My understanding is that I am legally entitled to grant that license because the city isn't claiming copyright on the data. Its public domain and as such can be added. I think the current draft of the CTs was changed to accommodate such things. One thing I'm curious about is the terms about indemnifying the City of SF against possible harm resulting from using the data. Let's say hypothetically that some third party uses the data that you incorporated into OSM, crashed their car due to bad data, and hypothetically they could sue someone over it. Now the OSM license disclaims liability (on the part of OSMF?) but does that other idemnification apply? (Actually I'm not sure what I'm asking actually makes sense.) I understand your question and it does make sense. I'd think if they used our data under a license that disclaims liability that that would be the end of it but. Cheers, Gregory Arenius ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Address Node Import for San Francisco
of the differences are. I found some other weird burrs in the data as well, in terms of how it arranges addresses stacked on top of one another in tall buildings. Nothing that can't be dealt with in an import. If those stacks are actual addresses in use at that location I was planning on leaving them that way. Do you have other thoughts on how to handle them? I know in some instances that they're probably not actually stacked, eg, they're for different businesses that have locations along the front of the building but I'm not sure how to deal with that. In some cases, especially multi-family residences the stack is correct in that its at the entrance for all of the addresses in the stack. Thanks, Gregory Arenius ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] Is this click through agreement compatible with OSM?
On Sat, Dec 11, 2010 at 4:27 AM, Steve Bennett stevag...@gmail.com wrote: On Fri, Dec 10, 2010 at 9:16 AM, Gregory Arenius greg...@arenius.com wrote: city changed the click through to address those problems. The agreement is located here: http://gispub02.sfgov.org/website/sfshare/index2.asp. See this clause: These Terms of Use do not grant You any title or right to any such intellectual property rights that the City or others may have in the GIS Data. Translation: You don't own it. The full clause is: IV. City's intellectual property rights not affected If the City claims or seeks to protect any patent, copyright, or other intellectual property rights in any GIS Data, the website will so indicate in the file containing such GIS Data or on the page from which such GIS Data is accessed. These Terms of Use do not grant You any title or right to any such intellectual property rights that the City or others may have in the GIS Data. I read this as saying that the terms of use, which are there as a hold harmless waiver, don't grant any rights. It specifically states that if the city is claiming copyright on the data it will do so in the file or on the website that the file is accessed from. The file in question has no such claims. Now see this clause: You agree to only add Contents for which You are the copyright holder Translation: You don't own it, you can't add it. I believe you're refering to the CTs. My understanding is that the current draft states: You represent and warrant that, to the best of your knowledge, You are legally entitled to grant the licence in Sections 2 and 3 below. My understanding is that I am legally entitled to grant that license because the city isn't claiming copyright on the data. Its public domain and as such can be added. I think the current draft of the CTs was changed to accommodate such things. (I'm glad this isn't just about Nearmap now.) I sympathize with the Nearmap issues but I'm not sure that this is a comparable situation. I've heard a lot of differing opinions on this issue but my reading is that everything is okay. I don't just want to steamroll through if other people think otherwise but I do think that we're okay using this data. Is there a way to get a more definitive reading of things? A working group or something? Cheers, Gregory Arenius ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Is this click through agreement compatible with OSM?
The city of San Francisco has made a bunch of geo data available. I plan on importing the address nodes so that we can have door to door routing for San Francisco and for geocoding purposes. I just want to see if the click through is compatible. My understanding is that the data is basically public domain and the agreement is mostly a hold harmless type of thing. This is based on my reading of it and what they city has told me they intend it to be. I have asked about this before and there were problems but the city changed the click through to address those problems. The agreement is located here: http://gispub02.sfgov.org/website/sfshare/index2.asp. Thoughts? Cheers, Greg ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-us] Address Node Import for San Francisco
I've been working on an import of San Francisco address node data. I have several thoughts and questions and would appreciate any feedback. About the data. Its in a shapefile format containing about 230,000 individual nodes. The data is really high quality and all of the addresses I have checked are correct. It has pretty complete coverage of the entire city. First, I've looked at how address nodes have been input manually. In some places they are just addr:housenumber and addr:street and nothing else. In other places they include the city and the country and sometimes another administrative level such as state. Since the last three pieces of information can be fairly easily derived I was thinking of just doing the house number and the street. The dataset is fairly large so I don't want to include any extra fields if I don't have to. Is this level of information sufficient? Or should I include the city and the state and the country in each node? Also, there are a large number of places where there are multiple nodes in one location if there is more than one address at that location. One example would be a house broken into five apartments. Sometimes they keep one address and use apartment numbers and sometimes each apartment gets its own house number. In the latter cases there will be five nodes with different addr:housenumber fields but identical addr:street and lat/long coordinates. Should I keep the individual nodes or should I combine them? For instance, I could do one node and have addr:housenumber=5;6;7;8;9 or have a node for each address. Combining nodes would cut the number of nodes imported by about 40% but I fear that it might be harder to work with manually and also not recognized by routers and other software. Before importing the data I will run a comparison against existing OSM data and not upload nodes that match an existing addr:housenumber/addr:street combination. There aren't many plain address nodes in the city at the moment (a couple hundred, tops) but there are a fair number of businesses that have had address data added to them and I don't want any duplicate address nodes as a result of this import. There are only a very few address ways in the SF dataset but they aren't any where near as accurate as the data I will be importing so I plan on deleting those. I haven't yet looked into how I plan to do the actual uploading but I'll take care to make sure its easily reversible if anything goes wrong and doesn't hammer any servers. I've also made a wiki page for the import.http://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import Feedback welcome here or on the wiki page. Cheers, Gregory Arenius ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Node Import for San Francisco
On Thu, Dec 9, 2010 at 3:20 PM, Serge Wroclawski emac...@gmail.com wrote: On Thu, Dec 9, 2010 at 6:00 PM, Gregory Arenius greg...@arenius.com wrote: I've been working on an import of San Francisco address node data. I have several thoughts and questions and would appreciate any feedback. The Wiki page doesn't mention the original dataset url. I have a few concerns:http://gispub02.sfgov.org/website/sfshare/catalog/sfaddresses.zip The shapefile is here.http://gispub02.sfgov.org/website/sfshare/catalog/sfaddresses.zip I added it to the wiki. I'm sorry, it should have been there to start with. 1) Without seeing the dataset url, it's hard to know anything about the dataset (its age, accuracy, etc.) This is a real problem with imports- knowing the original quality of the dataset before it's imported. The project has had to remove or correct so many bad datasets, it's incredibly annoying. I've spot checked a number of blocks by going out and comparing the data and been impressed with its accuracy. The data is sourced from the Department of Building Inspection's Address Verification System, the Assessor-Recorder Office's Parcel database and the Department of Elections (Voter Registration Project). I believe it to be high quality and have been told by another that has used it that the dataset is legit. About the data. Its in a shapefile format containing about 230,000 individual nodes. The data is really high quality and all of the addresses I have checked are correct. It has pretty complete coverage of the entire city. MHO is that individual node addresses are pretty awful. If you can import the building outlines, and then attach the addresses to them, great (and you'll need to consider what's to be done with any existing data), but otherwise, IMHO, this dataset just appears as noise. The wiki states that this is how address nodes are done. They can be attached to other objects of course but they can also be independent. Like I stated earlier I did check how they are actually being done elsewhere and the ones I've seen entered are done in this manner. Also, why do you think of them as noise? They're useful for geocoding and door to door routing. The routing in particular is something people clamor for when its lacking. As for attaching them to buildings that doesn't particularly work well in many cases especially in San Francisco. For instance a building might have a number of addresses in it. A large building taking up a whole block could have addresses on multiple streets. Also, we don't have building outlines for most of SF and that shouldn't stop us from having useful routing. Also, there are a large number of places where there are multiple nodes in one location if there is more than one address at that location. One example would be a house broken into five apartments. Sometimes they keep one address and use apartment numbers and sometimes each apartment gets its own house number. In the latter cases there will be five nodes with different addr:housenumber fields but identical addr:street and lat/long coordinates. Should I keep the individual nodes or should I combine them? Honestly, I think this is a very cart-before-horse. Please consider making a test of your dataset somewhere people can check out, and then solicit feedback on the process. As I'm still planning things out I think its a good time to discuss this type of issue. As to a test, what do you recommend? Tossing the OSM file up somewhere for people to see or did you mean more testing the upload process on a dev server type of thing. I'm planning on doing both but if you have other ideas that might help I'm listening. I haven't yet looked into how I plan to do the actual uploading but I'll take care to make sure its easily reversible if anything goes wrong and doesn't hammer any servers. There are people who've spent years with the project and not gotten imports right, I think this is a less trivial problem than you might expect. I hear this every time imports come up. I got it. Its hard. Thats why I'm soliciting feedback and willing to take my time and am really trying to do it correctly. I'm not willing to just give up because there have been problems with imports in the past. I've also made a wiki page for the import. Feedback welcome here or on the wiki page. This really belongs on the imports list as well, but my feedback would be: 1) Where's the shapefile? (if for nothing else, than the licnese, but also for feedback) I added it to the wiki page. Again I'm sorry it wasn't there to begin with. The shapefile is here.http://gispub02.sfgov.org/website/sfshare/catalog/sfaddresses.zipAs for the license I believe its okay but I posted that bit to talk legal because I thought it belonged there. 2) Can you attach the addresses to real objects (rather than standalone nodes)? Generally speaking, no. We don't
Re: [Talk-us] Address Node Import for San Francisco
A few comments... 1) San Francisco explicitly says they do not have building outline data. :( So, I suppose we get to add buildings ourselves. I do see that SF does have parcels. For DC, we are attaching addresses to buildings when there is a one-to-one relation between them. When there are multiple address nodes for a single building, then we keep them as nodes. In vast majority of cases, we do not have apartment numbers but in some cases we have things like 1120a, 1120b, 1120c that can be imported. Obviously, without a buildings dataset, our approach won't quite apply for SF. We mostly only have building shapes drawn in downtown where its unlikely there will be many one-to-one matches. I wish we did have a building shape file though, that would be great. I have thought about using the parcel data but I'm not sure thats as useful. 2) I don't consider the addresses as noise. The data is very helpful for geocoding. If the renderer does a sloppy job making noise out of addresses, the renderings should be improved. 3) Having looked at the data catalogue page, I do have concerns about the terms of use and think it's best to get SF to explicitly agree to allow OSM to use the data. http://gispub02.sfgov.org/website/sfshare/index2.asp What terms in particular caused you concern? I'll need to know if I'm going to ask for explicit permission. A while back I posted the previous terms to talk legal and they pointed out problems. The city changed the license when I pointed out that it cause problems for open project (apparently that was in the works anyway). I thought those problems were removed. I had a conference call with one of the datasf.org people the helps make city datasets available and an assistant city attorney prior to those changes and I was told that unless specifically noted otherwise in the dataset that the data was public domain. I do understand that that isn't in writing though. If there is a problem with the terms though there is still a good chance the city would give us explicit permission to use the data; they seemed excited about the prospect of some of it ending up in OSM. 4) If you can get explicit permission, then I suggest breaking up the address nodes into smaller chunks (e.g. by census block group), convert them to osm format with Ian's shp-to-osm tool, and check them for quality and against existing OSM data (e.g. existing pois w/ addresses) in JOSM before importing. QGIS and/or PostGIS can be useful for chopping up the data into geographic chunks. This approach gives opportunity to apply due diligence, to check things, and keep chunks small enough that it's reasonably possible to deal with any mistakes or glitches. I had been planning on using shp-to-osm to break it in to chunks by number of nodes but doing it geographically makes more sense. Do you think census block size is best or maybe by neighborhood or aim for an approximate number of nodes in each geographic chunk? Cheers, Gregory Arenius ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] JOSM shp file plugin
Hi, There isn't a day gone past where the vast gaps in the OSM dataset, the missing address nodes, missing turn restrictions, missing building outlines, missing subdivisions, missing everything and whatnot don't hugely degrade the usefulness of the project. OSM is not a data dumping ground, OSM is a community project. Importing all these things without a community to support them is worth less than nothing, it hurts the project rather than helping it. If you have a shape file with building outlines, configure your Mapnik instance to render the buildings from that. So anybody who wants to see building outlines should spend thousands of hours tracing them by hand, a mind numbingly boring, tedious task or just run their own private Mapnik instance and render with that? What kind of statement is that? Why don't you go configure your Mapnik not to use any data from an import and use that instead? Its not a fair statement to make. There is a huge amount of data out there that is under an acceptable license to import into OSM that would be a great asset to the project. No, no, and no again. OSM is not a pool to collect the free geodata of the world. Because you are right - there is an *awful* lot of geodata available and we do _not_ want to burden our infrastructure with dead stuff that nobody cares about. You really don't think that there is data out there that we could import that would be an asset to the project? None? At all? Sure, there is data out there that we don't need and don't want in OSM because its not as good as what we've got or its not the type of data that the project is about and we don't need to burden our infrastructure with that. I'm not saying that we should be a dumping ground of free geodata and that everything out there should go in. I'm say that there is a lot of great stuff out there and we should figure out how to bring that in. You can say just go collect it manually but if we know the data is already there we're not going to put in years of work duplicating it just to appease this anti-import mindset that some on this list have. Let's say it is a pro-community mindset. Prove that there's the manpower and the interest to maintain the imported data and you might have a point. I've put in a lot of transit data, such as bus stops, by hand. How do you prove that there is the manpower and interest to keep this updated? You can't. In fact, the city updates their GTFS feed more often and more accurately than I can hope to keep up with all the changes they make by doing everything on foot. It is something that people use and would like to see in OSM so it certainly isn't dead stuff. What we need is a good toolchain to do imports and be able to import changes from upstream sources like tiger and GTFS feeds where appropriate. The US has lots of free data. You seem to think that importing this data hurts the US because people who just look at the map don't see open spaces to fill in and therefore don't contribute and create community. That if only we didn't do imports the community would form to gather the data by hand and everything would be good. I don't think this is the case. A community didn't form in the US pre-tiger import when the map was a blank slate here. We didn't because we knew that data was there and that importing that data would make a lot more sense than trying to duplicate it. Take for instance the San Francisco address data that I've been working on cleaning up so that it can be imported. Having address data in OSM makes it a much more useful dataset, especially for routing. As far as addresses go in San Francisco a few shops and restaurants currently have them entered in OSM. There also a couple dozen blocks that have address range ways alongside them. Other than that there is no address data at all in OSM for San Francisco. We can import this dataset which is really pretty good to start with and will be even better once I've cleaned it up a bit more. It will probably be about 200k nodes. At a rough estimate, given how many miles of streets would need to be walked and how much data would have to be input I'd say it would take somewhere between 3-6 thousand man hours to duplicate. Why should we not do it? Just because we can't prove that we'll be able to maintain it? Its not like the addresses jump around frequently. I know that in Europe, especially Germany, the whole army of mappers with boots on the ground thing is working really well and thats great. Over here in the US we don't have that. It would be nice if we did but we don't. What we do have is a lot of PD government data, much of which is constantly being maintained and updated by the government. Lots of us would like to work with what we have and make good use of those government datasets, some of which are really good. I guess I'm just frustrated that anytime someone even thinks the word 'import' that they suffer an onslaught of condescending
Re: [OSM-talk] JOSM shp file plugin
On 10/20/10 09:52, Sam Vekemans wrote: I'm wondering if it is in the works to have a JOSM plugin where it can automatically convert shp files (ie. run shp-to-osm.jar in the background), No, that would only encourage people to do even more mindless imports than we have already. There's not a day gone past without somebody, somewhere, importing data without talking to anyone first - overwriting existing data, creating duplicate nodes, ignoring license questions, not thinking about updates, and whatnot. There isn't a day gone past where the vast gaps in the OSM dataset, the missing address nodes, missing turn restrictions, missing building outlines, missing subdivisions, missing everything and whatnot don't hugely degrade the usefulness of the project. How is the set of problems you mentioned any worse than the missing data, much of which we could get through imports? Imports are a complex topic and they require a lot of thought and discussion. Making imports easier will enable everyone to go through the steps technically without necessarily having the proper understanding of OSM that is required. Making your toolchain so difficult to use that people can't get anything done just so that they won't make mistakes while doing it is a completely backwards way of going about things. There is a huge amount of data out there that is under an acceptable license to import into OSM that would be a great asset to the project. You can say just go collect it manually but if we know the data is already there we're not going to put in years of work duplicating it just to appease this anti-import mindset that some on this list have. I know this mindset came about because of all of the problems that have resulted from different imports but the solution to this is a better set of tools and a better set of documentation for those tools. The solution is not making imports more difficult to do as that will just create more of the aforementioned data import problems. I think a JOSM shp plugin would be extremely useful. Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] list of user IDs having accepted the contributor terms
Any info on who, or at least what percentage of people, clicked on the all my edits are public domain checkbox? Just curious. Cheers, Greg On Sat, Oct 9, 2010 at 11:22 AM, Matt Amos zerebub...@gmail.com wrote: as part of the voluntary relicensing phase of the move to ODbL, existing contributors have had the ability to voluntarily accept the contributor terms. to help the community assess the impact of the relicensing it was planned to make the information about which accounts have agreed available. this will help with the evaluation of the process and analysis of any consequent data loss, should the switch be made. at the last LWG meeting, having been put to the board for approval, it was decided to make this available [1], and i'm pleased to announce that this list is now up [2] and being regularly refreshed from the database every hour. i look forward to seeing the new analyses, visualisations and tools that can be built using this data. cheers, matt [1] https://docs.google.com/View?id=dd9g3qjp_86hf7fnqg8 [2] http://planet.openstreetmap.org/users_agreed/users_agreed.txt ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-us] San Francisco Mappy Hour
Hi Folks, We're having a Mappy Hour social meetup in San Francisco on Wednesday October 20th at 6:00 PM. We'll be at Jillian's which is a restaurant and bar at 101 4th Street in the Metreon. Its on the OSM Bay Area meetup.comhttp://www.meetup.com/Bay-Area-OpenStreetMappers/calendar/15014653/page as well. Hope to see you there! Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] San Francisco Mappy Hour
Hi Folks, We're having a Mappy Hour social meetup in San Francisco on Wednesday October 20th at 6:00 PM. We'll be at Jillian's which is a restaurant and bar at 101 4th Street in the Metreon. Its on the OSM Bay Area meetup.comhttp://www.meetup.com/Bay-Area-OpenStreetMappers/calendar/15014653/page as well. Hope to see you there! Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-transit] bus stops/platforms with electronic display of when the buses pass through
Hi, For bus stops I use ticker=yes/no. I'm sure I saw that documented somewhere and didn't come up with it on my own but a fairly exhaustive wiki search to provide a link for you came up completely dry so who knows. Cheers, Greg On Fri, Oct 1, 2010 at 1:39 PM, Jo winfi...@gmail.com wrote: Hi, I didn't find a tag to use for synoptic displays indicating when buses are coming through (either as a time left to wait, or a full display of normal time+delay) at the bus stop level. And another one (at the bus_station level) with all the buses that are passing through (like the ones in train stations and airports). That one may even deserve its own node to indicate where it is and possibly even an indication in what direction it's facing. Jo ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [OSM-talk] Waze and OSM in Chile
Noam, Out of curiosity...I imagine you folks investigated just using the OSM data directly even if you have to give attribution? What made you decide to go with other data providers that you have to pay for? Was it coverage or routability or? I'm only asking because on the surface it looks like it would be a decent fit. Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Is this clickthrough agreement compatible with OSM?
Replying to myself here but... The city sent me a prompt reply to my email. They're big fans of our work and would like to help. I will probably be meeting with one of them in the coming week to discuss ways that we can collaborate and what data sets we would like access to. I wanted to ask here what exactly I need to ask for with respect to licensing? Just explicit permission to use the data in OSM? Anything else? Thanks, Greg On Wed, Aug 25, 2010 at 5:11 AM, Gregory Arenius greg...@arenius.comwrote: I must have missed that particular section somehow. I sent off an email to ask the city if we could get the data under a license we could use. We'll see what happens. As to how many OSMers are in the city its hard to say exactly. There are a few people working on the map pretty frequently and a lot of one time editors who just edit one or two points. Interestingly one of the last one time editors had the user name Monica at sfgov. Greg ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-us] San Francisco Geodata
San Francisco has a website at datasf.org that has a lot of good geodata on it. The current licence isn't acceptable for using any of the data but they might be willing to give us permission to use it. Some of the datasets that I thought were interesting were city lotshttp://gispub02.sfgov.org/website/sfshare/catalog/citylots.zip, addresseshttp://gispub02.sfgov.org/website/sfshare/catalog/sfaddresses.zip, neighborhoodshttp://gispub02.sfgov.org/website/sfshare/catalog/planning_neighborhoods_tiybi.zip, landusehttp://gispub02.sfgov.org/website/sfshare/catalog/planning_landuse.zip, public landshttp://gispub02.sfgov.org/website/sfshare/catalog/sflnds_public.zip, street centerlineshttp://gispub02.sfgov.org/website/sfshare/catalog/stclines.zip, speed limitshttp://gispub02.sfgov.org/website/sfshare/catalog/dpt_speedlimits.zipand the bike networkhttp://gispub02.sfgov.org/website/sfshare/catalog/dpt_bike_network.zip . We have good street data for San Francisco so the street centerline file would mostly be useful to check for errors and inform us about which streets really don't have a name. We need addresses if we want to have usable data for routing programs. The addresses file has them in point format. The city lots file also has addresses or address ranges for each parcel. Has anybody done imports of similar address data? If so, did you keep it in a point format or convert it into the parallel ways format? How did things turn out? I would really like to put that address data into OSM if I can get permission from the city to use it for that purpose. The speed limits would be useful for routing as well. Also, just to be clear, even if the city grants permission for us to use this data I certainly don't plan on just 'dumping' it into OSM. We already have good data for San Francisco. I'm more interested in using it to refine what we already have and plan on taking it slow and doing any imports the right way. I'd love to hear any thoughts or ideas or what other locals would like to see our map have. I'm probably going to be meeting with someone from the city next week to discuss the licence issue and ways we can collaborate. Anything in particular you folks are interested in? Cheers, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] Is this clickthrough agreement compatible with OSM?
I must have missed that particular section somehow. I sent off an email to ask the city if we could get the data under a license we could use. We'll see what happens. As to how many OSMers are in the city its hard to say exactly. There are a few people working on the map pretty frequently and a lot of one time editors who just edit one or two points. Interestingly one of the last one time editors had the user name Monica at sfgov. Greg ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Over-digitized imports?
Computer storage and processing time are relatively cheap and only getting cheaper at an exponential rate. OSM volunteer time is very limited. Given those facts I wouldn't worry about unsmoothing except in particularly egregious cases. I just don't see the benefit in decreased storage and processing costs as being worth anywhere near the cost in man hours it would take to do the unsmoothing work. Cheers, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Unnamed Streets
Is there any recommended way to deal with streets with no names? I don't mean streets that have a name and we just haven't added that to OSM yet. I mean, how do we deal with streets that really don't have a name. I've seen two courses of action used. One is to just leave the name field blank and the other is to name the street unnamed street or unnamed road. We could also add a tag named=no to specify that the street really has no name. What do people feel is the best way to do this? Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unnamed Streets
Thanks. My searches for unnamed completely missed noname. Cheers, Greg On Fri, Aug 20, 2010 at 12:34 AM, Pierre-Alain Dorange pdora...@mac.comwrote: Gregory Arenius greg...@arenius.com wrote: Is there any recommended way to deal with streets with no names? I don't mean streets that have a name and we just haven't added that to OSM yet. I mean, how do we deal with streets that really don't have a name. According to the wiki (1) you can used noname=yes. There is alos a proposal for noname (2) (1) http://wiki.openstreetmap.org/wiki/Key:name (2) http://wiki.openstreetmap.org/wiki/Proposed_features/Noname -- Pierre-Alain Dorange ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-us] SOTM-US Synopsis
Since I would like to hear more about what goes on at some of the conferences I can't make I thought I would post some of what stuck out the most for me at this one. This is just what stuck out to me. If I miss something or am wrong about something I apologize in advance. I actually mailed this off a few days ago but it seems not to have found its way to the list so here is a second attempt. Nama Budhathoki gave a good presentation (over Skype!) on who the contributors to OSM are and why they do what they do. It had breakdowns of how much people contributed verse what their reasons for contributing were. It also had a bit on the backgrounds of OSMers such as age, gender, and traditional GIS experience. Randal Hale and Leah Keith gave a talk about using OSM as a teaching tool with high school students. Her students seemed to really take to it. It was also very good because it doesn't cost theschool any money if they already have computers. The FREE component was really important. They can just make accounts and get started. They used Mapzen because they found it to be the most user friendly. Even after the class project some of the students have continued to contribute useful data to the map. Jon Nystrom gave a talk about ArcGIS being able to work directly with OSM files. Many attendees were excited about this because many people in attendance came from a GIS background and 'grew up on' ArcGIS. People like to use the tools they know. It will probably help more professionals contribute to OSM because they won't have to learn a new tool set. David Cole gave a talk about Mapquest starting to use and examine Mapquest data. The next day David Nesbitt gave a talk on how Mapquest routing can work with OSM data in their testbed. Basically Mapquest is looking at using OSM data instead of proprietary data sources. They plan on contributing back to OSM in kind and with financial support. The routing data talked some about shortcomings in the OSM data set especially in the US. Some problems were missing turn restrictions, bad topology (missing connections or connections that don't actually exist), handling of roads to ferry terminals, and driveways tagged as residential roads. Oh, and addressability. One mentioned strength was good road classifications as their routing algorithm relies on that pretty heavily. They're using a mostly open stack except for their routing algorithm. They've released they're stylesheets under an open licence but they're still a work in progress. They have a big tile server that is for open use that can handle pretty much anything we can throw at it; if I recall correctly something like 4000 requests a second. You can check out their work at http://open.mapquest.co.uk. Really awesome stuff. I'm excited by the possibility that the maps I help make could touch that many people. Wicked cool. Lars Ahlzen gave a talk on TopOSM, an OSM based topographic map of the US. Its a really cool map optimized for looks and not speed. http://toposm.com Learon Dalby gave a talk about getting government data into OSM from the government side. He is part of (head of???) the Arkansas (AR!) GIS team. They've collected a lot of good data and have released it for free for anyone to use and he would really like to see it in OSM. The main problem is how to get it into OSM. There was a general consensus (don't quote me on that!) that there isn't really a set of well defined best practices or a good tool chain to make this happen and go smoothly at that large of a scale. Also, OSMers usually only work on areas that interest them and there aren't many OSMers in AR. Another problem was how to flag changes we make to the data set and send those flags back upstream. They wouldn't be able to take our edits directly but just knowing where changes needed to be made would be a huge help to them. I think it rocks that the whole open data movement has made it to the point where there are people in government who are not merely willing to make data available but that actually want us to use it and are willing to expend time and effort to make that happen. Carl Anderson had a similar talk the next day about using government data. He suggested that using GIS conflation and road matching tools might help ease imports some even if we have to translate to a GIS format and back. OpenJump in particular was mentioned as being a good open source tool for that purpose. He also mentioned how checking the merged data with different renderers and stylesheets was helpful because they all have different strengths and weaknesses. Ian Dees talked about using shp-2-osm to import data into OSM. We had the OSM-US annual meeting. OSM-US is incorporated, is trying to become a certified non-profit, and has approximately $250 in its vast coffers. Voting for the new board kicked off and will be open to OSM-US members for the next two weeks. Voting will be run on a survey monkey platform by outside observers
[Talk-us] SOTM-US
Since I would like to hear more about what goes on at some of the conferences I can't make I thought I would post some of what stuck out the most for me at this one. This is just what stuck out to me. If I miss something or am wrong about something I apologize in advance. Nama Budhathoki gave a good presentation (over Skype!) on who the contributors to OSM are and why they do what they do. It had breakdowns of how much people contributed verse what their reasons for contributing were. It also had a bit on the backgrounds of OSMers such as age, gender, and traditional GIS experience. Randal Hale and Leah Keith gave a talk about using OSM as a teaching tool with high school students. Her students seemed to really take to it. It was also very good because it doesn't cost theschool any money if they already have computers. The FREE component was really important. They can just make accounts and get started. They used Mapzen because they found it to be the most user friendly. Even after the class project some of the students have continued to contribute useful data to the map. Jon Nystrom gave a talk about ArcGIS being able to work directly with OSM files. Many attendees were excited about this because many people in attendance came from a GIS background and 'grew up on' ArcGIS. People like to use the tools they know. It will probably help more professionals contribute to OSM because they won't have to learn a new tool set. David Cole gave a talk about Mapquest starting to use and examine Mapquest data. The next day David Nesbitt gave a talk on how Mapquest routing can work with OSM data in their testbed. Basically Mapquest is looking at using OSM data instead of proprietary data sources. They plan on contributing back to OSM in kind and with financial support. The routing data talked some about shortcomings in the OSM data set especially in the US. Some problems were missing turn restrictions, bad topology (missing connections or connections that don't actually exist), handling of roads to ferry terminals, and driveways tagged as residential roads. Oh, and addressability. One mentioned strength was good road classifications as their routing algorithm relies on that pretty heavily. They're using a mostly open stack except for their routing algorithm. They've released they're stylesheets under an open licence but they're still a work in progress. They have a big tile server that is for open use that can handle pretty much anything we can throw at it; if I recall correctly something like 4000 requests a second. You can check out their work at http://open.mapquest.co.uk. Really awesome stuff. I'm excited by the possibility that the maps I help make could touch that many people. Wicked cool. Learon Dalby gave a talk about getting government data into OSM from the government side. He is part of (head of???) the Arkansas (AR!) GIS team. They've collected a lot of good data and have released it for free for anyone to use and he would really like to see it in OSM. The main problem is how to get it into OSM. There was a general consensus (don't quote me on that!) that there isn't really a set of well defined best practices or a good tool chain to make this happen and go smoothly at that large of a scale. Also, OSMers usually only work on areas that interest them and there aren't many OSMers in AR. Another problem was how to flag changes we make to the data set and send those flags back upstream. They wouldn't be able to take our edits directly but just knowing where changes needed to be made would be a huge help to them. I think it rocks that the whole open data movement has made it to the point where there are people in government who are not merely willing to make data available but that actually want us to use it and are willing to expend time and effort to make that happen. Carl Anderson had a similar talk the next day about using government data. He suggested that using GIS conflation and road matching tools might help ease imports some even if we have to translate to a GIS format and back. OpenJump in particular was mentioned as being a good open source tool for that purpose. He also mentioned how checking the merged data with different renderers and stylesheets was helpful because they all have different strengths and weaknesses. Ian Dees talked about using shp-2-osm to import data into OSM. We had the OSM-US annual meeting. OSM-US is incorporated, is trying to become a certified non-profit, and has approximately $250 in its vast coffers. Voting for the new board kicked off and will be open to OSM-US members for the next two weeks. Voting will be run on a survey monkey platform by outside observers from two different open source projects. You can vote even if you haven't joined yet. You just have to join before you vote. Thea Clay talked about building community and running mapping parties, mappy hours and mapathons. Steve mentioned that all of the successful
[Talk-us] Pre-SOTM-US Gathering
Are there any plans for a get together at a bar or restaurant tonight in Atlanta before we kick things off tommorow? If there aren't yet does anyone want to make some? Cheers, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
I would love to see GTFS data imported into OSM, especially the SF data if you can convince them to change the license. I think the street= tag is a good idea. I'm unsure of the bearing tag. If we know which street the stop is on and where the stop is the direction the bus is going follows from that. Could you provide an example of where and how that would come in useful? Or is it something that we need to know only if the imported location of the stop is not precise enough to show which side of the street it is on? How are you planning to deal with existing data? Many stops are already mapped and have more data than is in the GTFS feed. For example, does the stop have a shelter, or a ticker to show when the next bus is coming or a bench, etc. Cheers, Greg ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] tagging stops served by multiple routes by more than one transit agency
When I tag bus stops with multiple operators I add the operator name to the route_ref. In the above example of HART and USF I would tag the stop as: operator=hart;usf hart_route_ref=5;12 usf_route_ref=A;C I always include route information in my bus stop tagging. I think it is more than just placeholder information. For instance, an application showing bus stops on a map should allow you to hover over the stop and see which routes it serves. If the stop doesn't include this data within its tags then you have to search through all the relations too get that data. Its simpler if the data is already in the bus stop node. Also, if you're trying to build a map of the system from the ground up instead of using an import (say, if the city in question didn't release its GTFS feed under an appropriate license) then its really a necessity to tag the stops completely to allow someone else creating the relation later to know which stops to include. Cheers, Greg ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
