Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Les scripts ne généreraient ils pas plein de choses dans error.log d'apache ? J'ai trouvé 154Go de log... peut être quelques trucs pas trop indispensables dedans à retirer, non ? Le 25 février 2014 22:01, Tyndare tynd...@wanadoo.fr a écrit : Le 24 février 2014 13:26, Christian Quest cqu...@openstreetmap.fr a écrit : Le 24 février 2014 11:26, Tyndare tynd...@wanadoo.fr a écrit : Le 23/02/2014 10:28, Christian Quest a écrit : Il manque à mon avis un fichier mix entre les points isolés et les points sur façade. Cela correspond aussi à ma façon de mapper, je vais essayer de faire quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour déterminer la direction ou projeter le numéro). Ah oui, c'est une info qui peut aider, mais il faut faire attention car il y aura forcément des numéros non orientés vu la disparité dans les données vectorielles du cadastre. J'ai rajouté un nouveau fichier de sortie, qui correspond au mix point en façade ou point isolé. L'angle avec lequel le numéro est dessiné sur le cadastre n'est utilisé pour projeter sur la façade que: - si le numéro n'est pas dessiné horizontalement, sinon c'est une projection orthogonale qui est faite. - et que si la projection n'arriverais bas trop de biais sur la façade (incidence max de 30°), sinon le point adresse reste isolé. Les numéros sont fusionnés aux bâtiments jusqu'à 2m de distance. Je peux adapter ces paramètres si vous pensez que les valeurs actuelles peuvent poser problème. L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne proposer que des fichiers correspondant à ce consensus histoire d'avoir au final des données homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde entier). Manifestement on arrivera pas à un consensus entre nous, donc je suis d'accord avec Vincent et Pieren: il faudrait élargir cette discussion. L'outil peut être utilisé plus largement maintenant je pense, du moins pour contribuer dans les zones où il n'y a encore aucune adresse dans OSM. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Bonsoir, Le 05/03/2014 22:18, Christian Quest a écrit : Les scripts ne généreraient ils pas plein de choses dans error.log d'apache ? J'ai trouvé 154Go de log... peut être quelques trucs pas trop indispensables dedans à retirer, non ? Quelques, oui, peut-être :) Ce serait intéressant d'avoir quelques lignes de ces logs (hors liste) pour analyse. Certaines grosses communes ont eu des plantages récemment. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
le log complet est sur /more/error.log.0 en cours de bzippage... avec un chmod a+r donc lisible par tous sauf erreur. Le 5 mars 2014 22:33, Vincent de Château-Thierry v...@laposte.net a écrit : Bonsoir, Le 05/03/2014 22:18, Christian Quest a écrit : Les scripts ne généreraient ils pas plein de choses dans error.log d'apache ? J'ai trouvé 154Go de log... peut être quelques trucs pas trop indispensables dedans à retirer, non ? Quelques, oui, peut-être :) Ce serait intéressant d'avoir quelques lignes de ces logs (hors liste) pour analyse. Certaines grosses communes ont eu des plantages récemment. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du bâti. Le 5 mars 2014 22:53, Christian Quest cqu...@openstreetmap.fr a écrit : le log complet est sur /more/error.log.0 en cours de bzippage... avec un chmod a+r donc lisible par tous sauf erreur. Le 5 mars 2014 22:33, Vincent de Château-Thierry v...@laposte.net a écrit : Bonsoir, Le 05/03/2014 22:18, Christian Quest a écrit : Les scripts ne généreraient ils pas plein de choses dans error.log d'apache ? J'ai trouvé 154Go de log... peut être quelques trucs pas trop indispensables dedans à retirer, non ? Quelques, oui, peut-être :) Ce serait intéressant d'avoir quelques lignes de ces logs (hors liste) pour analyse. Certaines grosses communes ont eu des plantages récemment. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Le 05/03/2014 23:07, Tyndare a écrit : Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du bâti. Même constat : aucune mention 'adresse' sur les 154 Go, mais beaucoup de Qadastre, y compris du contenu brut (des coordonnées) : ça peut rapidement faire du volume. À surveiller dans les prochains jours ? vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
ok, donc je peux virer ce log ? Le 5 mars 2014 23:27, Vincent de Château-Thierry v...@laposte.net a écrit : Le 05/03/2014 23:07, Tyndare a écrit : Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du bâti. Même constat : aucune mention 'adresse' sur les 154 Go, mais beaucoup de Qadastre, y compris du contenu brut (des coordonnées) : ça peut rapidement faire du volume. À surveiller dans les prochains jours ? vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Pour moi oui pas de souci. Le 5 mars 2014 23:33, Christian Quest cqu...@openstreetmap.fr a écrit : ok, donc je peux virer ce log ? Le 5 mars 2014 23:27, Vincent de Château-Thierry v...@laposte.net a écrit : Le 05/03/2014 23:07, Tyndare a écrit : Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du bâti. Même constat : aucune mention 'adresse' sur les 154 Go, mais beaucoup de Qadastre, y compris du contenu brut (des coordonnées) : ça peut rapidement faire du volume. À surveiller dans les prochains jours ? vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Le 05/03/2014 23:33, Christian Quest a écrit : ok, donc je peux virer ce log ? à mon avis oui. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev] Am I alone here?
I am afraid I am irritating you folks with my focus on errors in the OSM source data. If so, I just apologize for that in advance. Of course, as in the science and research generally, it is much more attractive to work on something new than working on something already done. OSM community is no exception and maybe therefore there is very little effort dedicated to errors, especially to systematic errors. Systematic errors are having same, or similar causes. They are present in a huge number and distributed all over the World. It is difficult to see them, detect them and correct/repair them. Usual editors based one-by-one correction is meaningless. The DO-ocracy principle does not work here and diffs based maintenance does not help either. These errors are accumulating, and (probably) permanently there and reflected in any publicly available OSM based mapping systems. One could say - he must be wrong, he is using wrong source data interpretation and the like. But careful. What if I am right? What if these systematic errors really exist and accumulate. Well, we do not need to be scientists to understand where this leads in the long term. And this is my concern. But I feel I am pretty alone here. When I try to move the attention to these systematic error issues by discussing and asking questions, people are irritated and, eventually, formally answering them. Even if I attach obvious and unbeatable arguments I receive answers like: I don't see the problem, I don't understand what are you trying to achieve, I am not here to argue with you, Well, take an editor an correct the errors and so on. Of course all these does not help the (OSM) community. Systematic errors should be prevented by eliminating their causes instead of curing the consequences. Let me give an example. Some days ago a mapper sked an the Help Forum the following question: How to make a hole in an area, eg woodland.. There were given 6 to 8 answers all incomplete (strictly taken - wrong) as how to upload a (new) complex area instead of how to convert an existing simple area into a complex area. Any of the instructions leads to existence of two almost overlapping areas one as a simple and one as a complex area (with a hole). The outer border polygons will lie in a thin corridor belt of each other (note, not overlapping) and the hole will never be visible. There is a huge number of these area error cases. The number of systematic error classes, volume of each, the permanent nature of them. indicates to me that I am pretty alone here. So, if you share/have the same concern let us cope jointly. Even better, if already vi have a forum/list that should work on systematic errors, let us know which one is that and join them. Regards, Sandor. PS. More about systematic errors, their causes, examples, illustration. you may find (download from) here: https://drive.google.com/file/d/0B6qGm3k2qWHqOXdmdFE2alVmdm8/edit?usp=sharin g ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Startup notes not matching current version
On 04.03.2014 23:27, Vincent Privat wrote: 2014-03-04 10:48 GMT+01:00 Dirk Stöcker openstreet...@dstoecker.de: Probably because nobody thought there are changes important enough to be noted there. It's rather the opposite, there's a ton of notable new features in January release (less in February, rather bug-fixing oriented). But I find it better when it's not a developer summering up, it reflects better the user point of view. That's a small task that could be easily done by our user community from the SVN changelog for purists of summarized changelog (which we maintain). Remember all: JOSM website is a wiki, everyone can help! All true, but the simple answer is that I do not have much time for JOSM ATM and only some few users ever changed this page. Sadly, that is true for the whole wiki in English and German, where lots of pages are outdated or do not even exist. cu colliar signature.asc Description: OpenPGP digital signature ___ josm-dev mailing list josm-...@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Am I alone here?
Sandor, On 03/05/2014 04:11 PM, Sandor Seres wrote: I am afraid I am irritating you folks with my focus on errors in the OSM source data. I think the reason for there being little echo to your message(s) is not so much the content but the style of the message(s). They are 1. too long 2. contain links to Google Documents 3. which are even longer 4. AND SOMETIMES THE SUBJECTS ARE IN CAPITAL LETTERS. Generally, your messages sound a bit like: Hey! People! Stop! Don't you see you're DOING IT WRONG! I have found that you are making SYSTEMATIC ERRORS But we all know that already. The reason why we're not overly concerned is: * for every new error introduced, we get a couple hundred features without errors, so the ratio is still good. * we have much worse problems than islands in lakes or so. * you are also, I believe, misusing the term systematic. In my mapping, I haven't introduced any of the errors that you mention. If the error were systematic then surely it would affect everyone's mapping, no? From this, in my opinion, ill-analyzed and over-exaggerated problem you jump to the conclusion that repairing these issues in editors does not work here (which seems to be your reason for not starting). But in fact we have a couple of mechanisms to cope with such issues - e.g. KeepRight or the OSM Inspector will highlight a number of common problems and make it easier for people to fix them, or newer-generation tools like MapRoulette or Kort which lend a gaming aspect to these tasks. But it seems that you don't even know about any of these which makes your analysis look relatively weak. At the end of your document you recommend to move the focus from fixing these to preventing them, which is not a bad idea; surely you have studied the JOSM editor's validator, and a comparable component present in the online iD editor, and had a look at which types of problems it already highlights when uploading? I am sure there is a lot that could be done to reduce the amount of errors that people make, or the detect these and make them visible so they can be fixed. It is, however, not enough to write: I think something should be done about this.; it is better to write: I would like to help coding X, where should I start, whom should I talk to? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Am I alone here?
On Wed, Mar 5, 2014 at 4:11 PM, Sandor Seres sandor...@gmail.com wrote: Some days ago a mapper sked an the Help Forum the following question: How to make a hole in an area, eg woodland.. There were given 6 to 8 answers all incomplete (strictly taken - wrong) as how to upload a (new) complex area instead of how to convert an existing simple area into a complex area. Any of the instructions leads to existence of two almost overlapping areas one as a simple and one as a complex area (with a hole). The outer border polygons will lie in a thin corridor belt of each other (note, not overlapping) and the hole will never be visible. There is a huge number of these area error cases. If you refer to this question: https://help.openstreetmap.org/questions/8129/how-to-make-a-hole-in-an-area-eg-woodland It was posted the 25th Sept 2011, not some days ago. It is true that the most voted up answer (on 3 answers, not 6 or 8) is today a bit obsolete about iD. But this is normal. iD is the new online editor and is constantly evolving. The other systematic errors you mention in your googledoc is more about rendering issues. Pieren ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Am I alone here?
Sandor Seres wrote: ... and maybe therefore there is very little effort dedicated to errors, especially to systematic errors. Er what? There's a lot of effort going into all of the following: 1) developing tools that enable new mappers to not make errors in the first place 2) detecting errors (things that are unlikely or impossible, based on other things mapped) 3) helping new mappers get to grips with mapping tools and map their surroundings If you doubt that (2) and (3) occur I suggest that you pop in to one of the country IRC channels where there is a new mappers and notes feed after there's been a press article about OSM, such as #osm-gb. Systematic errors are having same, or similar causes. They are present in a huge number and distributed all over the World. It is difficult to see them, detect them and correct/repair them. What would be useful here would be some sort of example the sorts of errors that you're talking about and (even better!) a suggestion as to how a particular systematic error might be avoided. If you look at the issues list for the iD editor (i.e. (1) in the list above) you'll see lots of discussion balancing making it easy for people to contribute and making what people contribute more likely to be correct. It's not easy; please don't assume that people haven't had all of these discussions already. Usual editors based one-by-one correction is meaningless. I disagree here. If something's been added to the map that's physically impossible it's really useful that the various QA sites flag it as an error. However in most cases to resolve it someone will need to get out from behind their computer keyboard and Go And Have A Look, because if an error that an online QA site can spot is there, who knows what else is wrong? Merely removing the indication that there is a problem on the QA site doesn't make what's in OSM match reality. So, can you give an example of a systematic error that occurs in OSM data (I can think of a few, but they're really common new mapper mistakes, and as such easily corrected by resurvey), and can you give a suggestion as how to prevent / fix them? Cheers, Andy ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Am I alone here?
The overlapping water areas one might be a good example. Like, say, in some dreamy future the OSM editor could be tactile and as you trace a riverbed and near an area of the same riverbed that's already been traced your mouse bounces back. Yes, that would be great. Dreamer's disclaimer: I am not intending to criticize anyone with this email. And I like tracing riverbeds. A -- Alex On Wed, Mar 5, 2014 at 11:40 PM, SomeoneElse li...@mail.atownsend.org.ukwrote: Sandor Seres wrote: ... and maybe therefore there is very little effort dedicated to errors, especially to systematic errors. Er what? There's a lot of effort going into all of the following: 1) developing tools that enable new mappers to not make errors in the first place 2) detecting errors (things that are unlikely or impossible, based on other things mapped) 3) helping new mappers get to grips with mapping tools and map their surroundings If you doubt that (2) and (3) occur I suggest that you pop in to one of the country IRC channels where there is a new mappers and notes feed after there's been a press article about OSM, such as #osm-gb. Systematic errors are having same, or similar causes. They are present in a huge number and distributed all over the World. It is difficult to see them, detect them and correct/repair them. What would be useful here would be some sort of example the sorts of errors that you're talking about and (even better!) a suggestion as to how a particular systematic error might be avoided. If you look at the issues list for the iD editor (i.e. (1) in the list above) you'll see lots of discussion balancing making it easy for people to contribute and making what people contribute more likely to be correct. It's not easy; please don't assume that people haven't had all of these discussions already. Usual editors based one-by-one correction is meaningless. I disagree here. If something's been added to the map that's physically impossible it's really useful that the various QA sites flag it as an error. However in most cases to resolve it someone will need to get out from behind their computer keyboard and Go And Have A Look, because if an error that an online QA site can spot is there, who knows what else is wrong? Merely removing the indication that there is a problem on the QA site doesn't make what's in OSM match reality. So, can you give an example of a systematic error that occurs in OSM data (I can think of a few, but they're really common new mapper mistakes, and as such easily corrected by resurvey), and can you give a suggestion as how to prevent / fix them? Cheers, Andy ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
