[OSM-talk] List of changes from API only gives target tile of moved node
Hi List! I've fixed a misplaced node in a way and was waiting for the rendered tiles to be updated. I was expecting that both tiles are beeing updated the one where the node was and the one where the node was moved to. But unfortunately, only the tile the node was moved to was updated. Moved node is http://www.openstreetmap.org/browse/node/330565882 See list of changes for the here: http://www.openstreetmap.org/api/0.6/changes?start=2009-12-18T17:12:00Zend=2009-12-18T17:13:00zoom=12 So currently both mapnik and t...@h have a ghost way: http://osm.org/go/YeU8QNPU-- or http://www.informationfreeway.org/index.php?lat=19.27338224574216lon=-72.60056980823181zoom=12layers=BF000F or (if the tiles were updated meanwhile): http://wiki.openstreetmap.org/wiki/Image:Ghost-way.png I believe that nodes moved to another tile is not a rare case and therefore API should list both tiles in the list of changed tiles. Is API 0.6 meant to list both tiles (means, this is a bug) or is this possibly worth a feature request for API 0.7? Thoughts? Regards Andre ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List of changes from API only gives target tile of moved node
Hi, Andre Hinrichs wrote: See list of changes for the here: http://www.openstreetmap.org/api/0.6/changes?start=2009-12-18T17:12:00Zend=2009-12-18T17:13:00zoom=12 So currently both mapnik and t...@h have a ghost way: What you describe may be right, but the reasoning is not; the Mapnik map does not use the API to find out what has changed, but instead relies on the diffs generated by Osmosis. Is API 0.6 meant to list both tiles (means, this is a bug) or is this possibly worth a feature request for API 0.7? Frankly, I think the changes call you're describing could well be removed altogether for 0.7 as it is very limited in the first place and does not seem to offer any advantages over running Osmosis and retrieving the changesets. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List of changes from API only gives target tile of moved node
Am Sonntag, den 20.12.2009, 19:12 +0100 schrieb Frederik Ramm: Hi, Andre Hinrichs wrote: See list of changes for the here: http://www.openstreetmap.org/api/0.6/changes?start=2009-12-18T17:12:00Zend=2009-12-18T17:13:00zoom=12 So currently both mapnik and t...@h have a ghost way: What you describe may be right, but the reasoning is not; the Mapnik map does not use the API to find out what has changed, but instead relies on the diffs generated by Osmosis. Then why does Mapnik show the same behaviour than t...@h? If Mapnik would take the diffs of Osmosis than it would have recognised that the tile has changed, wouldn't it? Is API 0.6 meant to list both tiles (means, this is a bug) or is this possibly worth a feature request for API 0.7? Frankly, I think the changes call you're describing could well be removed altogether for 0.7 as it is very limited in the first place and does not seem to offer any advantages over running Osmosis and retrieving the changesets. I'm pretty sure, that at least t...@h uses it currently. But if there is an easy (fast) way to get the changed tiles out of the diffs than it could possibly be adapted. Does creating the changes via osmosis have less limitations than the API way? If yes, which? Anyway, if not many services use it (except t...@h) it would not create a high load on the server, so why drop it? Andre ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List of changes from API only gives target tile of moved node
Hi, Andre Hinrichs wrote: Then why does Mapnik show the same behaviour than t...@h? The osc file doesn't list the old position of the node. You could find out by querying your local database for the old position but this is deemed too much cost for too little gain. Does creating the changes via osmosis have less limitations than the API way? If yes, which? You can generate a list of changes for any interval (provided you have the matching .osc files available of course), and for any zoom level. Anyway, if not many services use it (except t...@h) it would not create a high load on the server, so why drop it? I think it is certainly an odd one out among the API calls; no other API call concerns itself with tile numbers of a spherical Mercator projection. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] List of changes from API only gives target tile of moved node
On Sun, Dec 20, 2009 at 8:17 PM, Frederik Ramm frede...@remote.org wrote: Andre Hinrichs wrote: Anyway, if not many services use it (except t...@h) it would not create a high load on the server, so why drop it? I think it is certainly an odd one out among the API calls; no other API call concerns itself with tile numbers of a spherical Mercator projection. it seems like something that trapi [1] could calculate more effectively than the main API, given that trapi must know which data tiles have been updated with each diff. cheers, matt [1] http://wiki.openstreetmap.org/wiki/Trapi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
