Hello Stéphane D.,
j'espère que ça va si je réponds en anglais, ça me prendrait un peu trop de temps en français.
To use your example with the arboretum, obviously you don't need to hang a tag at each branch of a tree as long as the tag at the trunk is visible. Hanging a visible tag somewhere would correspond to the act of rendering. But that doesn't change the fact that each branch belongs to a certain tree. This is the difference between the renderer, who needs to decide what kind of detail is appropriate for each zoom level, and the underlying data, that can contain much richer information.
And if you look at a long branch at a zoom level where the trunk might be out of sight, or if you are looking at a place where branches of different trees are almost touching each other, it can be useful to know which branch belongs to which tree without going back to the trunk. Again, I think this decision should be up to the rendering algorithm. For an example of a "label overkill" (done by a questionable rendering algorithm), have a look at with how many labels the Chemin de Montéclard in Epalinges is rendered in the Bing map: http://www.bing.com/maps/?v=2&cp=rrrfzbhjnpgy&lvl=19.41&dir=348....
But ultimately, my point is a different one: Since I have started mapping in 2010, it happened again and again that Stéphane Brunner felt compelled to "correct" and "improve" information that I had just freshly put on the map, making sure to have everything "his way", and at best notifying me after the fact if at all - not to seek an agreement, but to lecture me about "my error". Moreover, I find it slightly ironic that the very same guy, who felt last year the urge to separate the land cover to the left and right from my forest tracks in order to "represent the physical width" of the tracks, thus creating three times the amount of ways and data to maintain (see here: http://www.openstreetmap.org/user/Shernott/diary/14754), feels now the urge to delete information that he deems "abusive", i.e. not of interest to him.
Thorsten
On 21.07.2012 21:44, Stéphane Dewarrat wrote:> Je suis désolé pour Thorsten, je crois que c'est inutile de nommer tous
les chemins annexes (service) à une rue nommée sur le terrain. Ce serait comme si dans un arboretum, il y aurait une plaquette sur chaque branche d'un pommier disant que c'est un pommier... Le lecteur d'une carte devine que c'est attaché au chemin principal et que les bâtiments le long de ces chemins annexes ont comme adresse le chemin principal. J'ai d'ailleur mappé quelques maisons et ajouter le tag addr:street avec le nom du chemin. Je pense que ce serait plus utile. Donc je suis l'avis de mon homonyme.
I totally support the idea of tagging the "branches". It is useful and as long as the information is accurate, I can't find any reason to remove it.
Bon dimanche à tous:
Ruben Le 21 juil. 2012 22:50, tnk@gmx.net a écrit :
Hello Stéphane D.,
j'espère que ça va si je réponds en anglais, ça me prendrait un peu trop de temps en français.
To use your example with the arboretum, obviously you don't need to hang a tag at each branch of a tree as long as the tag at the trunk is visible. Hanging a visible tag somewhere would correspond to the act of rendering. But that doesn't change the fact that each branch belongs to a certain tree. This is the difference between the renderer, who needs to decide what kind of detail is appropriate for each zoom level, and the underlying data, that can contain much richer information.
And if you look at a long branch at a zoom level where the trunk might be out of sight, or if you are looking at a place where branches of different trees are almost touching each other, it can be useful to know which branch belongs to which tree without going back to the trunk. Again, I think this decision should be up to the rendering algorithm. For an example of a "label overkill" (done by a questionable rendering algorithm), have a look at with how many labels the Chemin de Montéclard in Epalinges is rendered in the Bing map:
http://www.bing.com/maps/?v=2&cp=rrrfzbhjnpgy&lvl=19.41&dir=348....
But ultimately, my point is a different one: Since I have started mapping in 2010, it happened again and again that Stéphane Brunner felt compelled to "correct" and "improve" information that I had just freshly put on the map, making sure to have everything "his way", and at best notifying me after the fact if at all - not to seek an agreement, but to lecture me about "my error". Moreover, I find it slightly ironic that the very same guy, who felt last year the urge to separate the land cover to the left and right from my forest tracks in order to "represent the physical width" of the tracks, thus creating three times the amount of ways and data to maintain (see here: http://www.openstreetmap.org/user/Shernott/diary/14754), feels now the urge to delete information that he deems "abusive", i.e. not of interest to him.
Thorsten
On 21.07.2012 21:44, Stéphane Dewarrat wrote:> Je suis désolé pour Thorsten, je crois que c'est inutile de nommer tous
les chemins annexes (service) à une rue nommée sur le terrain. Ce serait comme si dans un arboretum, il y aurait une plaquette sur chaque branche d'un pommier disant que c'est un pommier... Le lecteur d'une carte devine que c'est attaché au chemin principal et que les bâtiments le long de ces chemins annexes ont comme adresse le chemin principal. J'ai d'ailleur mappé quelques maisons et ajouter le tag addr:street avec le nom du chemin. Je pense que ce serait plus utile. Donc je suis l'avis de mon homonyme.
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Salut/Hi Stéphane and Thorsten
Ruben wrote:
I totally support the idea of tagging the "branches". It is useful and as long as the information is accurate, I can't find any reason to remove it.
Je suis d'accord avec ça: street branchens don't "inherit" names. Of course we all support that we dont' edit for the renderer - but that for example doesn't mean that we put all tag's into relations.
I'd really would like to support Sarah's proposition to Stéphane to *first* ask this list before deleting someone other's work (systematically?). Mediating seems rather difficult given this medium.
I've taken a random sample out of the change set http://www.openstreetmap.org/browse/node/983813495/history mentioned before and found this: There was a bus_stop,which has been edited before 4 times, Thorsten (Shernott) last, situated in the middle of the street. Then user Stéphane deleted all tags of this node and turned it into a naked one. Then Stéphane entered a brand new bus_stop nearby little bit above the street.
I would recommend that (possibly) misplaced objects are never deleted, but moved if you want to enhance the location.
In case of this bus_stop, there is no reason to me to move it away from the middle of the street. This seems to be not only a useless edit but an edit which makes it impossible to track the history of OSM objects - e.g. to give feedback to DIDOK project about enhancements.
Yours, Stefan
2012/7/22 RB tanrub@gmail.com:
I totally support the idea of tagging the "branches". It is useful and as long as the information is accurate, I can't find any reason to remove it.
Bon dimanche à tous:
Ruben
Le 21 juil. 2012 22:50, tnk@gmx.net a écrit :
Hello Stéphane D.,
j'espère que ça va si je réponds en anglais, ça me prendrait un peu trop de temps en français.
To use your example with the arboretum, obviously you don't need to hang a tag at each branch of a tree as long as the tag at the trunk is visible. Hanging a visible tag somewhere would correspond to the act of rendering. But that doesn't change the fact that each branch belongs to a certain tree. This is the difference between the renderer, who needs to decide what kind of detail is appropriate for each zoom level, and the underlying data, that can contain much richer information.
And if you look at a long branch at a zoom level where the trunk might be out of sight, or if you are looking at a place where branches of different trees are almost touching each other, it can be useful to know which branch belongs to which tree without going back to the trunk. Again, I think this decision should be up to the rendering algorithm. For an example of a "label overkill" (done by a questionable rendering algorithm), have a look at with how many labels the Chemin de Montéclard in Epalinges is rendered in the Bing map:
http://www.bing.com/maps/?v=2&cp=rrrfzbhjnpgy&lvl=19.41&dir=348....
But ultimately, my point is a different one: Since I have started mapping in 2010, it happened again and again that Stéphane Brunner felt compelled to "correct" and "improve" information that I had just freshly put on the map, making sure to have everything "his way", and at best notifying me after the fact if at all - not to seek an agreement, but to lecture me about "my error". Moreover, I find it slightly ironic that the very same guy, who felt last year the urge to separate the land cover to the left and right from my forest tracks in order to "represent the physical width" of the tracks, thus creating three times the amount of ways and data to maintain (see here: http://www.openstreetmap.org/user/Shernott/diary/14754), feels now the urge to delete information that he deems "abusive", i.e. not of interest to him.
Thorsten
On 21.07.2012 21:44, Stéphane Dewarrat wrote:> Je suis désolé pour Thorsten, je crois que c'est inutile de nommer tous
les chemins annexes (service) à une rue nommée sur le terrain. Ce serait comme si dans un arboretum, il y aurait une plaquette sur chaque branche d'un pommier disant que c'est un pommier... Le lecteur d'une carte devine que c'est attaché au chemin principal et que les bâtiments le long de ces chemins annexes ont comme adresse le chemin principal. J'ai d'ailleur mappé quelques maisons et ajouter le tag addr:street avec le nom du chemin. Je pense que ce serait plus utile. Donc je suis l'avis de mon homonyme.
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
New subject, as it is not really related to the initial mail.
On Sun, Jul 22, 2012 at 12:43:12PM +0200, Stefan Keller wrote:
I've taken a random sample out of the change set http://www.openstreetmap.org/browse/node/983813495/history mentioned before and found this: There was a bus_stop,which has been edited before 4 times, Thorsten (Shernott) last, situated in the middle of the street. Then user Stéphane deleted all tags of this node and turned it into a naked one. Then Stéphane entered a brand new bus_stop nearby little bit above the street.
I would recommend that (possibly) misplaced objects are never deleted, but moved if you want to enhance the location.
I agree to that in theory but in practice JOSM is really a pain when it comes to removing nodes from ways.
In case of this bus_stop, there is no reason to me to move it away from the middle of the street. This seems to be not only a useless edit but an edit which makes it impossible to track the history of OSM objects - e.g. to give feedback to DIDOK project about enhancements.
Not really. We don't need the history of objects. It is only necessary that the uic_ref is preserved in order to give feedback about the DIDOK stuff.
See datendelphin's new map that compares current Didok and OSM as an example: http://didok.osmd.ch It makes the comparisons purely based on uic_ref.
Gruss
Sarah
Hi Sarah
2012/7/22 Sarah Hoffmann lonvia@denofr.de:
New subject, as it is not really related to the initial mail.
On Sun, Jul 22, 2012 at 12:43:12PM +0200, Stefan Keller wrote:
I've taken a random sample out of the change set http://www.openstreetmap.org/browse/node/983813495/history mentioned before and found this: There was a bus_stop,which has been edited before 4 times, Thorsten (Shernott) last, situated in the middle of the street. Then user Stéphane deleted all tags of this node and turned it into a naked one. Then Stéphane entered a brand new bus_stop nearby little bit above the street.
I would recommend that (possibly) misplaced objects are never deleted, but moved if you want to enhance the location.
I agree to that in theory but in practice JOSM is really a pain when it comes to removing nodes from ways.
JOSM is not supporting this? And I thought it's the best OSM editor around... ;-> But still: as you're answer implies, it's possible though and it's even desirable. I should add this to the JOSM feature wishlist.
In case of this bus_stop, there is no reason to me to move it away from the middle of the street. This seems to be not only a useless edit but an edit which makes it impossible to track the history of OSM objects - e.g. to give feedback to DIDOK project about enhancements.
Not really. We don't need the history of objects. It is only necessary that the uic_ref is preserved in order to give feedback about the DIDOK stuff.
See datendelphin's new map that compares current Didok and OSM as an example: http://didok.osmd.ch It makes the comparisons purely based on uic_ref.
I see (and many thanks to your hint service - I know I should have kown this... :->).
What remains to me is the following, since I'm having in mind OSM which is more and more related to "external databases". First, I'm still convinced that the principle of update (versus delete and recreate) should hold also for OSM. Second, we seem to have a problem with stable id's in OSM (osm_id).
Having external id's in OSM now seems to me like a necessity (in order to become related to external dbs) and a concession to the fact the OSM doesn't have stable ids. At least it's also an indication or flag to OSM users.
Greetings/Grüsse/Salutations Stefan
On Sun, Jul 22, 2012 at 01:40:48PM +0200, Stefan Keller wrote:
Hi Sarah
2012/7/22 Sarah Hoffmann lonvia@denofr.de:
New subject, as it is not really related to the initial mail.
On Sun, Jul 22, 2012 at 12:43:12PM +0200, Stefan Keller wrote:
I've taken a random sample out of the change set http://www.openstreetmap.org/browse/node/983813495/history mentioned
It was just brought to my attention that this bus stop may even not exist anymore. Anybody care to go for a walk and have a look? :)
I would recommend that (possibly) misplaced objects are never deleted, but moved if you want to enhance the location.
I agree to that in theory but in practice JOSM is really a pain when it comes to removing nodes from ways.
JOSM is not supporting this? And I thought it's the best OSM editor around... ;-> But still: as you're answer implies, it's possible though and it's even desirable. I should add this to the JOSM feature wishlist.
It it possible with the unglue function. But especially in a case like the above where the node is on the middle of an intersection, things get very messy. (And don't even get me started on relations... ;)
What remains to me is the following, since I'm having in mind OSM which is more and more related to "external databases". First, I'm still convinced that the principle of update (versus delete and recreate) should hold also for OSM. Second, we seem to have a problem with stable id's in OSM (osm_id).
Having external id's in OSM now seems to me like a necessity (in order to become related to external dbs) and a concession to the fact the OSM doesn't have stable ids. At least it's also an indication or flag to OSM users.
One of the big TODOs of OSM. Closest thing we have at the moment is Rolands proposal base on the Overpass API: http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
Problem is that it is pretty hard to define what is 'stable' in the context of OSM. How should splitting of ways be handled? What if a shop moves to the next building? What if we split the bus stops into two, one for each direction? So, we actually end up with a n-to-n relation: one OSM object might have multiple UIDs (for the shop, for the building, for the address...) and a UID might reference multiple OSM objects (split ways).
Sarah
Hello Stefan,
Ce Nœud n'est pas du tout le sujet du conflit, mais ce que tu propose me parais irréalisable de moins avec JOSM.
Si tu a une façon de faire pour conserver l'historique je serais curieux de savoir comment :-)
Quand au fait de ne pas mettre le nœud sur la route mais du bon côté et toujours utile pour savoir de quel côté de la route ce trouve l’arrêt de bus.
On est plut un confis pour des chemins comme ceux-ci: http://www.openstreetmap.org/browse/way/171925486 http://www.openstreetmap.org/browse/way/171767901
Salutations Stéphane
2012/7/22 Stefan Keller sfkeller@gmail.com:
Salut/Hi Stéphane and Thorsten
Ruben wrote:
I totally support the idea of tagging the "branches". It is useful and as long as the information is accurate, I can't find any reason to remove it.
Je suis d'accord avec ça: street branchens don't "inherit" names. Of course we all support that we dont' edit for the renderer - but that for example doesn't mean that we put all tag's into relations.
I'd really would like to support Sarah's proposition to Stéphane to *first* ask this list before deleting someone other's work (systematically?). Mediating seems rather difficult given this medium.
I've taken a random sample out of the change set http://www.openstreetmap.org/browse/node/983813495/history mentioned before and found this: There was a bus_stop,which has been edited before 4 times, Thorsten (Shernott) last, situated in the middle of the street. Then user Stéphane deleted all tags of this node and turned it into a naked one. Then Stéphane entered a brand new bus_stop nearby little bit above the street.
I would recommend that (possibly) misplaced objects are never deleted, but moved if you want to enhance the location.
In case of this bus_stop, there is no reason to me to move it away from the middle of the street. This seems to be not only a useless edit but an edit which makes it impossible to track the history of OSM objects - e.g. to give feedback to DIDOK project about enhancements.
Yours, Stefan
2012/7/22 RB tanrub@gmail.com:
I totally support the idea of tagging the "branches". It is useful and as long as the information is accurate, I can't find any reason to remove it.
Bon dimanche à tous:
Ruben
Le 21 juil. 2012 22:50, tnk@gmx.net a écrit :
Hello Stéphane D.,
j'espère que ça va si je réponds en anglais, ça me prendrait un peu trop de temps en français.
To use your example with the arboretum, obviously you don't need to hang a tag at each branch of a tree as long as the tag at the trunk is visible. Hanging a visible tag somewhere would correspond to the act of rendering. But that doesn't change the fact that each branch belongs to a certain tree. This is the difference between the renderer, who needs to decide what kind of detail is appropriate for each zoom level, and the underlying data, that can contain much richer information.
And if you look at a long branch at a zoom level where the trunk might be out of sight, or if you are looking at a place where branches of different trees are almost touching each other, it can be useful to know which branch belongs to which tree without going back to the trunk. Again, I think this decision should be up to the rendering algorithm. For an example of a "label overkill" (done by a questionable rendering algorithm), have a look at with how many labels the Chemin de Montéclard in Epalinges is rendered in the Bing map:
http://www.bing.com/maps/?v=2&cp=rrrfzbhjnpgy&lvl=19.41&dir=348....
But ultimately, my point is a different one: Since I have started mapping in 2010, it happened again and again that Stéphane Brunner felt compelled to "correct" and "improve" information that I had just freshly put on the map, making sure to have everything "his way", and at best notifying me after the fact if at all - not to seek an agreement, but to lecture me about "my error". Moreover, I find it slightly ironic that the very same guy, who felt last year the urge to separate the land cover to the left and right from my forest tracks in order to "represent the physical width" of the tracks, thus creating three times the amount of ways and data to maintain (see here: http://www.openstreetmap.org/user/Shernott/diary/14754), feels now the urge to delete information that he deems "abusive", i.e. not of interest to him.
Thorsten
On 21.07.2012 21:44, Stéphane Dewarrat wrote:> Je suis désolé pour Thorsten, je crois que c'est inutile de nommer tous
les chemins annexes (service) à une rue nommée sur le terrain. Ce serait comme si dans un arboretum, il y aurait une plaquette sur chaque branche d'un pommier disant que c'est un pommier... Le lecteur d'une carte devine que c'est attaché au chemin principal et que les bâtiments le long de ces chemins annexes ont comme adresse le chemin principal. J'ai d'ailleur mappé quelques maisons et ajouter le tag addr:street avec le nom du chemin. Je pense que ce serait plus utile. Donc je suis l'avis de mon homonyme.
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
RB -
Sarah Hoffmann -
Stefan Keller -
Stéphane Brunner -
tnk＠gmx.net