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
