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
[OSM-talk] JOSM shp file plugin
Hi, Seeing as how Potlatch2 now has the super powers ability to load the basic geometry (not attributes) of shp files, when providing the url to the .shp .prj (and frieds) 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), Apologies for sending to this list, as im not on the josm-dev list. Perhaps Merkaarator can/will be able to handle this? Thanks, Sam -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Hi, 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. 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. Any editor offering a simple shp import functionality would soon be regarded as the software that causes more harm than good. Calls for banning that editor would ensue. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Am 20.10.2010 11:45, schrieb Frederik Ramm: Any editor offering a simple shp import functionality would soon be regarded as the software that causes more harm than good. Calls for banning that editor would ensue. I think it would be okay to have shp files as background layer just like a WMS or a GPX Track, although I don't know if this could be useful. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Perhaps Merkaarator can/will be able to handle this? Merkaartor can open SHP file natively. Regards - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Thanks Chris, I'll choose your answer :-) I know that last time i attempted to play with Merkarater it was still a bit buggy, so im sure it's better now :) Great work! cheers, sam p.s BTW, it's on my list to see the map feature default presets, and compare it with the other editors/renderers/datasets to help the developers get them all in-sync. On 10/20/10, Chris Browet c...@semperpax.com wrote: Perhaps Merkaarator can/will be able to handle this? Merkaartor can open SHP file natively. Regards - Chris - -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
On Wed, Oct 20, 2010 at 12:50, Sam Vekemans acrosscanadatra...@gmail.comwrote: Thanks Chris, I'll choose your answer :-) To somewhat ease Frederik's worries, while you can upload SHP features, you have to specifically select and Force Dirty them. OTOH, by making the SHP layer readonly, it acts like a kind of vectorial WMS layer. - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Hi, On 10/20/10 13:20, Chris Browet wrote: To somewhat ease Frederik's worries, while you can upload SHP features, you have to specifically select and Force Dirty them. OTOH, by making the SHP layer readonly, it acts like a kind of vectorial WMS layer. I think that's what Potlatch does - display shapefiles as a background layer. But not convert and upload them. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
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-talk] JOSM shp file plugin
On 10/20/2010 10:16 AM, Gregory Arenius wrote: 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? Gregory, I use OSM data mainly to get maps for my Garmin device. Lately I was in an area where someone imported a set of data on top of existing data w/o taking the time to remove duplicates. Although the imported data was of better quality than the existing one, this import of better quality data worsened the overall quality in that area. Having two overlapping and unconnected set of roads just drove the GPS crazy: road calculation failed most of the time and when it succeeded it would take long detours. Bottom line is imports can be useful BUT they have to be done correctly. Thanks, N. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
Hi, On 10/20/10 16:16, Gregory Arenius wrote: 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. (Having said that, I would really like to see your suggestion for a shape file import that adds turn restrictions.) 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 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. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM shp file plugin
On Wed, 20 Oct 2010 16:52:54 +0200 Frederik Ramm frede...@remote.org wrote: Let's say it is a pro-community mindset. It certainly is incorrect to claim that for the Australian imported data. It has not detracted from our extremely small community. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] JOSM shp file plugin
I believe that imports into the Austraklian OSM data have been both of the good and bad kinds and have therefore both benifited but also detracted from the project and the community. If the data can be easily collected and mapped by survey, then importing it is always a very bad idea and OSM just becomes a dumping ground for low quality data. If the data is not easily collected by survey then importing it is probably a good idea, subject to certain restrictions. OK - first the good imports. The ABS data for suburbs and coastlines was a good thing for OSM since they appear to be high quality and are not easily to collect by survey. However I really wish that people would not glue them to roads, rivers etc. This is the similar problem to people gluing landuse polygons to roads which has already made the Canberra OSM map well nigh uneditable. Also, gluing ABS data to OSM data will make it very difficult to import the next, improved and updated ABS data. Now for the bad imports. 1) Gas station data. Although I have no interest in verifying fixing or maintaining any imported data, I thought I'd better check out the Queanbeyan imported data. I noticed that OSM now had a petrol station right next to the fire station. I knew this to be wrong so, after a quick drive past to make sure no one had built a new station the previous night,I deleted the bogus OSM data. I appears that the data providers had mistaken the address (from memory, 2 Lowe Street rather than the correct 46-48 Lowe Street) then geocoded it from somewhere and then published the wrong data. If someone had used the OSM data to try to find the nearest petrol station, they'd probably have run out of gas before they even got near it. 2) Weather station data. I checked the one that the imported data said was in Queanbeyan and it came as absolutely no surprise to me that it was no longer there. I belive that a few decades ago it way well have been there (in the grounds of a ladies bowling club). Canberra Bridges - the case for survey it, if at all possible Since it is relatively trivial to convert any amount of ACT grid co-ordinates to WSG84 geographic co-ordinates, I could have easily imported the ACT bridge date straight into OSM. Howevewr this would have been a bad import. I'm only about half way through visiting and photographing the number plates on the 900 or so bridges but already I have come across about two dozen cases where the official data is probably incorrect a) bridges that are no longer there b) missing bridges c) bridges position is wrong d) number plates are on wrong bridge (or data is transposed) I am notifyig the ACT Government of these issues so eventually OSM and the Govt will both have good data. To be fair, the Govt is in the process of fixing their bridge data since they have also reclassified what constitues a bridge. Similarly I could easily import the BBQ list but once I've finished the bridges, I'll then visit all the BBQs (theres only about a hundred of them so it shouldn't take too long. I really hope no one imports the Australian Toilet map date. It suggests that there is only one public toilet in Queanbeyan, which is a long way from reality. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
