Re: [OSM-dev] New OSM Test Data Repository
Jochen Topf joc...@remote.org wrote: It also depends on what you are testing. If you are testing the OSM XML parser, those cases are valid data that the OSM parser must understand. If you are testing the renderer, it might be different. For the renderer it would be nice to have a model village featuring all objects in the standard mapnik style. Apart from this I once set up a testfile for verification of correct rendering of riverwidths. Background: I learnt from a cartographer, that waterbodies should always be rendered in their real width on the ground. Probably also of interest to this database. Regards Sven -- Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär, und - dank Knut - insbesondere der Eisbär, deutlich größerer Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
Jochen Topf joc...@remote.org wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. Hm, you seem to user real osm id-numbers. Don't you think we should define a private id-range for this purpose? 900 and above might be a reasonable range. I think about importing such data into postgis for rendering tests and it might be bad in some cases if this would kill existing data. Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Mo, Feb 24, 2014 at 04:08:09 +, Sven Geggus wrote: Jochen Topf joc...@remote.org wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. Hm, you seem to user real osm id-numbers. Don't you think we should define a private id-range for this purpose? 900 and above might be a reasonable range. I think about importing such data into postgis for rendering tests and it might be bad in some cases if this would kill existing data. Creating test cases etc. is bad enough without having to count zeros in huge numbers. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Mo, Feb 24, 2014 at 03:55:37 +, Sven Geggus wrote: Jochen Topf joc...@remote.org wrote: It also depends on what you are testing. If you are testing the OSM XML parser, those cases are valid data that the OSM parser must understand. If you are testing the renderer, it might be different. For the renderer it would be nice to have a model village featuring all objects in the standard mapnik style. Apart from this I once set up a testfile for verification of correct rendering of riverwidths. Background: I learnt from a cartographer, that waterbodies should always be rendered in their real width on the ground. Probably also of interest to this database. For me that's out of scope. I am trying to test software not rendering style files. But if somebody else wants to tackle this, we can talk about whether it makes sense to put all of this in the same repository or how we can organize it best. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] New OSM Test Data Repository
I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. See my blog post at http://blog.jochentopf.com/2014-02-21-osm-test-data-repository.html for details. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Friday 21 February 2014, Jochen Topf wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. See my blog post at http://blog.jochentopf.com/2014-02-21-osm-test-data-repository.html for details. Nice. Of course I could not resist creating another test: http://www.imagico.de/files/data.osm where the result would be 'valid but invalid in plate carree or web mercator'. 'invalid but valid in plate carree and web mercator' is also possible of course, just like all other combinations. ;-) In case you wonder about the coordinates - that's (50 900) and (55 905) in UTM zone 47. And of course this does not work near the equator. -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Fr, Feb 21, 2014 at 08:05:34 +0100, Christoph Hormann wrote: On Friday 21 February 2014, Jochen Topf wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. See my blog post at http://blog.jochentopf.com/2014-02-21-osm-test-data-repository.html for details. Nice. Of course I could not resist creating another test: http://www.imagico.de/files/data.osm where the result would be 'valid but invalid in plate carree or web mercator'. 'invalid but valid in plate carree and web mercator' is also possible of course, just like all other combinations. ;-) In case you wonder about the coordinates - that's (50 900) and (55 905) in UTM zone 47. And of course this does not work near the equator. I am not sure yet what exactly the valid and invalid mean and whether we need different outcomes. For the moment valid means more something like: The data looks good, could exist in a real database, and everybody would agree on how to interpret it. While invalid is everything else. Say, for instance, that you have a way that contains the same node twice directly next to each other. Do you remove one occurence in the linestring geometry or not? You don't see the difference usually, so in almost all cases it does not matter. But there could be a difference. And it doesn't happen often in the data. But strictly speaking people shouldn't add data like that. So is that already invalid data? It also depends on what you are testing. If you are testing the OSM XML parser, those cases are valid data that the OSM parser must understand. If you are testing the renderer, it might be different. I expect different programs to use the same data.osm files from the repository, but decide for themselves which test case is valid and which isn't in their context. I haven't figured out all the details yet, for the moment I am trying to get the ball rolling, get started writing test data and tests programs that use them. We'll figure out the details along the way. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Friday 21 February 2014, you wrote: I am not sure yet what exactly the valid and invalid mean and whether we need different outcomes. For the moment valid means more something like: The data looks good, could exist in a real database, and everybody would agree on how to interpret it. While invalid is everything else. I suppose there are many cases where it would make sense to allow an assessment somewhere between 'fully valid no matter how hard you look at it' and 'invalid beyond any consistent interpretation of the data'. It might make sense to say robust programs should be able to deal with certain data while data producing progams should avoid generating such data. I haven't figured out all the details yet, for the moment I am trying to get the ball rolling, get started writing test data and tests programs that use them. We'll figure out the details along the way. It will be interesting to see results for multipolygons in various programs. I have long suspected the JOSM validator is fairly 'loose' in this regard (which is a bad thing - validation in the editor should ideally be the strictest check of all) but never got around to pinning this down. -- Christoph Hormann http://www.imagico.de/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
I am not sure yet what exactly the valid and invalid mean and whether we need different outcomes. For the moment valid means more something like: The data looks good, could exist in a real database, and everybody would agree on how to interpret it. While invalid is everything else. I suppose there are many cases where it would make sense to allow an assessment somewhere between 'fully valid no matter how hard you look at it' and 'invalid beyond any consistent interpretation of the data'. It might make sense to say robust programs should be able to deal with certain data while data producing progams should avoid generating such data. Yes. I'd add that any good consumer/production OSM-data-processor should (be able to) gracefully handle slightly invalid data. For example it should not segfault, abort or skip a linestring just because the way contains a node twice. The same tests could also be used against OSM-quality-assurance tools which of course should be able to detect the respective glitches. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
