Re: [OSM-dev] ESRI article sent by a friend
2010/7/12 Stefan de Konink ste...@konink.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 14:15, Mike N. schreef: If the filters are predefined and the data is never shown for editing or rendering, why have it? For the simple reason that there is not only one rendering of /the/ OpenStreetMap map. I can see the point in this, but I'd rather prefer an openimportmap with a separate database, where you can upload all kind of rubbish and keep the main OSM-db as clean as possible from imports. There are actually a lot of mappers that go out and collect unique geoinformation manually, and I think that this is the key feature of OSM. cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
Don't know if you can really make a hard cut, saying what is an import and what not. Or to make it more clear: What is the difference between a good import of some data that is 10 years old and a mapper that is drawing areas based on some landsat-imagery (which is as far as i know from 2003)? Both do add loads of data from a foreign source. I don't think that old or imported data is a problem, as long as the import-quality is okay. (e.g. do not import data that we already have (street on an street)). Jan Am 16.07.2010 12:32, schrieb M∡rtin Koppenhoefer: 2010/7/12 Stefan de Koninkste...@konink.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 14:15, Mike N. schreef: If the filters are predefined and the data is never shown for editing or rendering, why have it? For the simple reason that there is not only one rendering of /the/ OpenStreetMap map. I can see the point in this, but I'd rather prefer an openimportmap with a separate database, where you can upload all kind of rubbish and keep the main OSM-db as clean as possible from imports. There are actually a lot of mappers that go out and collect unique geoinformation manually, and I think that this is the key feature of OSM. cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
Outdated and wrong data won't correct itself as it ages. Not to pick on these guys, but http://www.openstreetmap.org/user/peoriagisupload Account for uploading automated edits of 1997 Peoria County planimetrics data. This data is freely available because of the caducity and decrepitude of the data. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
On Mon, Jul 12, 2010 at 1:37 PM, Stefan de Konink ste...@konink.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 07:25, Alan Mintz schreef: 1. It's not ignored if users have to stumble over duplicate data when editing and either reconcile (which should have been done by the importing person) or ignore it. Editor, software, issue. A good editor selectively filters out information, so that the user doesn't get an information overload (or worse: breaks other data) Unfortunately, the API itself doesn't do any filtering if you do a bbox request. You still download the excess data even if the editor is smart. And don't say that we can upgrade the API since that is quite disruptive and imports are happening right now. 2. If the import uses existing tags (as did my example), it _does_ get rendered. It is pretty trivial not to render anything from a specific user. That we currently don't do such thing doesn't mean we can't. Not trivial if the data has been touched by other users and is impossible if the data has been replaced by a completely new OSM feature with the same tags. For example, splitting a way will result into at least one completely new way which is not from the specific user with respect to the data. In addition, the importer might be using his normal user account without a guarantee that we can distinguish his import edits and his normal edits. 3. Adding lots of junk data expands the database, costing performance and real $$ with no benefit. Everything is slower with more data - downloads, editing, backups, etc. Also, it increases the number and complexity of chunks you have to chop areas into because of the object limit in the API. All with no benefit. The complete API design of OpenStreetMap sucks scalability wise. Having arbitrary limits on the length of paths, or the amount of data we /can/ import won't solve that bottleneck. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
1. It's not ignored if users have to stumble over duplicate data when editing and either reconcile (which should have been done by the importing person) or ignore it. Editor, software, issue. A good editor selectively filters out information, so that the user doesn't get an information overload (or worse: breaks other data) I think that editor and rendering toolchain developers should spend their time on more useful features, etc, rather than trying to exclude some arbitrary data set - which, as time goes on and more people touch the data becomes harder and harder to filter out. And you're asking thousands of other OSM contributors to construct their own filter set in order to begin editing without being overwhelmed. If the filters are predefined and the data is never shown for editing or rendering, why have it? 2. If the import uses existing tags (as did my example), it _does_ get rendered. It is pretty trivial not to render anything from a specific user. That we currently don't do such thing doesn't mean we can't. Referring to the same example as Alan used - there is no argument for poorly geo-located imports. The most frequent end result was companies plopped in the middle of roads, in some cases miles from actual locations; companies that hadn't existed for years. Outdated and wrong data won't correct itself as it ages. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 14:15, Mike N. schreef: If the filters are predefined and the data is never shown for editing or rendering, why have it? For the simple reason that there is not only one rendering of /the/ OpenStreetMap map. Referring to the same example as Alan used - there is no argument for poorly geo-located imports. Indeed, there is no argument for that. But that isn't the only thing that is available. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkw7DawACgkQYH1+F2Rqwn1uAgCeJudWlU/OYPHTA1B4mK4ssKxm GxMAn3J1OxAv/7EdusJHXlFK+gARCG5R =5Fct -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
At 2010-07-10 14:55, John Smith wrote: On 11 July 2010 07:32, Thomas Emge te...@esri.com wrote: ... Some like to think there is 2 types of importing, implopping is where people blindly upload data without checking what they are importing or what already exists, ...which is unacceptable in any area or type of data for which there may be existing data in OSM. A good example was the import of the EPA superfund data, which was poorly geo-referenced, not discussed with other users, woefully incomplete (for some unknown reason), and duplicative of existing data. It was eventually reverted. -- Alan Mintz alan_mintz+...@earthlink.net ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 06:57, Alan Mintz schreef: At 2010-07-10 14:55, John Smith wrote: On 11 July 2010 07:32, Thomas Emge te...@esri.com wrote: ... Some like to think there is 2 types of importing, implopping is where people blindly upload data without checking what they are importing or what already exists, ...which is unacceptable in any area or type of data for which there may be existing data in OSM. A good example was the import of the EPA superfund data, which was poorly geo-referenced, not discussed with other users, woefully incomplete (for some unknown reason), and duplicative of existing data. It was eventually reverted. So why is this /so/ unacceptable? The renderer decides what to render. If we end up in rendering only a specific subset of data, for example from a list of users that we trust. Then any import is just ignored, until something thinks its good enough to be used. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkw6pAgACgkQYH1+F2Rqwn01UQCeMvtUUtxmsJ710PLXEMYtkRW1 R8wAoI5Zn3S8ndDsIoVYn7XxBG0DQG2V =ukIX -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
On 12 July 2010 15:11, Stefan de Konink ste...@konink.de wrote: So why is this /so/ unacceptable? The renderer decides what to render. If we end up in rendering only a specific subset of data, for example from a list of users that we trust. Then any import is just ignored, until something thinks its good enough to be used. It's a simple cost verse benefit analysis, is the data going to be more beneficial than the effort needed to make it useful. If it causes a lot of duplication or extra work for minimal benefit then that kind of defeats the purpose of importing. Selective importing, or at least some kind of scripts that compare existing data with new data can help improve the noise to signal ratio considerably. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
At 2010-07-11 22:11, Stefan de Konink wrote: Op 12-07-10 06:57, Alan Mintz schreef: At 2010-07-10 14:55, John Smith wrote: On 11 July 2010 07:32, Thomas Emge te...@esri.com wrote: ... Some like to think there is 2 types of importing, implopping is where people blindly upload data without checking what they are importing or what already exists, ...which is unacceptable in any area or type of data for which there may be existing data in OSM. A good example was the import of the EPA superfund data, which was poorly geo-referenced, not discussed with other users, woefully incomplete (for some unknown reason), and duplicative of existing data. It was eventually reverted. So why is this /so/ unacceptable? The renderer decides what to render. If we end up in rendering only a specific subset of data, for example from a list of users that we trust. Then any import is just ignored, until something thinks its good enough to be used. 1. It's not ignored if users have to stumble over duplicate data when editing and either reconcile (which should have been done by the importing person) or ignore it. 2. If the import uses existing tags (as did my example), it _does_ get rendered. 3. Adding lots of junk data expands the database, costing performance and real $$ with no benefit. Everything is slower with more data - downloads, editing, backups, etc. Also, it increases the number and complexity of chunks you have to chop areas into because of the object limit in the API. All with no benefit. All, of course, in my own experience, which is admittedly somewhat less (in OSM) than others. -- Alan Mintz alan_mintz+...@earthlink.net ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] ESRI article sent by a friend
mhoge...@esri.com recommends this article from ESRI. Esri Releases ArcGIS Editor for OpenStreetMap: http://www.esri.com/news/releases/10_3qtr/openstreetmap.html ESRI has released a free and open source add-on to ArcGIS 10 for editing OSM. Details in the press release. Marten Hogeweg @martenhogeweg ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
There was a couple of other threads on other lists about this: http://lists.openstreetmap.org/pipermail/talk/2010-July/051583.html http://lists.openstreetmap.org/pipermail/imports/2010-July/000614.html Including some questions about relational support: http://lists.openstreetmap.org/pipermail/imports/2010-July/000617.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
If developers are interested in contributing to code/documentation/best practices, send me your codeplex name and I can add you as contributor. http://esriosmeditor.codeplex.com/ Marten ESRI Inc. @martenhogeweg -Original Message- From: John Smith [mailto:deltafoxtrot...@gmail.com] Sent: Saturday, July 10, 2010 11:37 AM To: Marten Hogeweg Cc: Dev@openstreetmap.org Subject: Re: [OSM-dev] ESRI article sent by a friend There was a couple of other threads on other lists about this: http://lists.openstreetmap.org/pipermail/talk/2010-July/051583.html http://lists.openstreetmap.org/pipermail/imports/2010-July/000614.html Including some questions about relational support: http://lists.openstreetmap.org/pipermail/imports/2010-July/000617.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
John, we are currently trapping for nodes and ways that are participating in a relation and the user is presented with a message like You are about to change a relation. Are you really, really sure that you want to continue?. We are not just modifying the relation without letting the user know. I might to change the wording on the documentation - that editing of relations (create, modify, and delete) is currently not possible. That fact you can modify and delete relations is probably secondary in nature as there is no easy editing experience for relations at this release. Something that would need to be added in the future. The hooks are certainly in place to do that but the user interface is not there. As far as (bulk) imports are concerned that functionality is missing as well (intentionally). As Lennard mentioned one should be careful to just take a shapefile and hit import. We would like to know if import capability is of interest and why. Just the fact that you want to upload your county's parcel data is not enough - or maybe it is, I don't know. If users are interested in doing so we will add a tool in the future. - Thomas From: dev-boun...@openstreetmap.org [dev-boun...@openstreetmap.org] On Behalf Of John Smith [deltafoxtrot...@gmail.com] Sent: Saturday, July 10, 2010 11:36 AM To: Marten Hogeweg Cc: Dev@openstreetmap.org Subject: Re: [OSM-dev] ESRI article sent by a friend There was a couple of other threads on other lists about this: http://lists.openstreetmap.org/pipermail/talk/2010-July/051583.html http://lists.openstreetmap.org/pipermail/imports/2010-July/000614.html Including some questions about relational support: http://lists.openstreetmap.org/pipermail/imports/2010-July/000617.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
On 11 July 2010 07:32, Thomas Emge te...@esri.com wrote: As far as (bulk) imports are concerned that functionality is missing as well (intentionally). As Lennard mentioned one should be careful to just take a shapefile and hit import. We would like to know if import capability is of interest and why. Just the fact that you want to upload your county's parcel data is not enough - or maybe it is, I don't know. If users are interested in doing so we will add a tool in the future. Some like to think there is 2 types of importing, implopping is where people blindly upload data without checking what they are importing or what already exists, then there is another type of importing, selectively importing, where selective features are imported, usually by having multiple layers and those features are copied and pasted between layers. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
