Re: [OSM-talk] Komuna e Malishevës, Serbia ?
Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
2012/4/1 Lester Caine les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
Well, personally, I don't really care, but saying than Malishevo is located in Serbia is certainly not less accurate than saying than it sits in Kosovo, since most of the world countries don't recognize Kosovo as a sovereign country. To be exact, it should be possible to say that it is in both countries. 2012/4/1 Mike Dupont jamesmikedup...@googlemail.com 2012/4/1 Lester Caine les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
Please : I am not making anymore bloody politics than people claiming that the situation is damn simple. I am a swiss citizen (not a Serb) and I really like all the people in Kosovo (KOA as well as KOS and the other ethnicities). It has nothing to do with taking side or whatever, but I am just saying that is is a complicated situation and that our map should try to reflect it. 2012/4/1 Lester Caine les...@lsces.co.uk Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.phphttp://www.firebirdsql.org/index.php __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
the map reflects it, we have right now the admin level of kosovo as less than a country. I noticed recently that the serbia relation contains it. In any case, osm is right now working hard to keep the community going, and I think that we need to make sure that the mappers are not offended when they look at their home town. I can imagine that osm will lose a bunch of dedicated mappers if the continue to offend people in that manner. mike 2012/4/1 RB tan...@gmail.com Please : I am not making anymore bloody politics than people claiming that the situation is damn simple. I am a swiss citizen (not a Serb) and I really like all the people in Kosovo (KOA as well as KOS and the other ethnicities). It has nothing to do with taking side or whatever, but I am just saying that is is a complicated situation and that our map should try to reflect it. 2012/4/1 Lester Caine les...@lsces.co.uk Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.phphttp://www.firebirdsql.org/index.php __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
this message bounced (too many recpt.) so i am sending it again : Ok people, I think we agreed here on the on the ground rule, kosovo is on the ground the republic of kosovo and not serbia. nothing you will say will change that fact. I have been there many times, and it is its own place, they have their own passports and these are recognized by germany and usa and uk etc. belgrad is not in fact control of kosovo, kosovo is its own country. I am sure that osm wants to keep the mappers there happy so they will continue mapping. lets stop this game and get back to work. please revert the changes to the database. 2012/4/1 Mike Dupont jamesmikedup...@googlemail.com the map reflects it, we have right now the admin level of kosovo as less than a country. I noticed recently that the serbia relation contains it. In any case, osm is right now working hard to keep the community going, and I think that we need to make sure that the mappers are not offended when they look at their home town. I can imagine that osm will lose a bunch of dedicated mappers if the continue to offend people in that manner. mike 2012/4/1 RB tan...@gmail.com Please : I am not making anymore bloody politics than people claiming that the situation is damn simple. I am a swiss citizen (not a Serb) and I really like all the people in Kosovo (KOA as well as KOS and the other ethnicities). It has nothing to do with taking side or whatever, but I am just saying that is is a complicated situation and that our map should try to reflect it. 2012/4/1 Lester Caine les...@lsces.co.uk Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.phphttp://www.firebirdsql.org/index.php __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] It has begun
OSM is in read-only mode as of 8:02 UTC. Looking at the minutely replication files, this was the last changeset to upload: http://www.openstreetmap.org/browse/changeset/11173886 Let's all wish the hard working admins good luck. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
RB wrote: It has nothing to do with taking side or whatever, but I am just saying that is is a complicated situation and that our map should try to reflect it. Actually I think something is broken with 'Location' ... Apparently Worcestershire is now in the East of England ... Ignoring the politics ... if the mechanism for creating a location does not work we don't have much chance of fixing anything? The complicated situation is working out what needs changing irrespective of anything else. Anyway edit access is not available now until the 4th, so perhaps in this case there was some vandalism prior to the database going to read-only :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
From: Lester Caine [mailto:les...@lsces.co.uk] Subject: Re: [OSM-talk] Komuna e Malishevës, Serbia ? Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. If you have reports of vandalism that the local community can't deal with, send them to d...@osmfoundation.org. Include lists of objects and changesets. Without those you can't tell who changed what. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) The best way I've found to debug the location information is to look up the location on http://nominatim.openstreetmap.org For the example diary entry linked, this gives you http://nominatim.openstreetmap.org/details.php?place_id=4568477 This tells you that the place is a place=hamlet node in the boundary=administrative relation Komuna e Malishevës (http://nominatim.openstreetmap.org/details.php?place_id=128946600) Now it gets complicated. The node is within three admin_level=2 or admin_level=3 boundaries. These are: http://www.openstreetmap.org/browse/relation/2088990 with name:en=Kosovo and Metohija admin_level=2 created March 18th http://www.openstreetmap.org/browse/relation/53295 with name:en=Kosovo and Metohija admin_level=2 created 2008. The admin_level started off as 3, was changed to 2 in July 2010 and back to admin_level=3 Feb 2012. The name was also changed from Kosovo to Kosovo and Metohija at the same time (in all languages). http://www.openstreetmap.org/browse/relation/1741311 with name:en=Serbia admin_level=2 created in 2011. Because regenerating all of the address data inside a country would be too much of a performance drain, they are cached for large boundary objects. My guess is what happened is at some point in the past the 53295 relation was broken and Nominatim cached it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevës, Serbia ?
OK, Thank you. Well this looks like the type of stuff we are dealing with recently. We mentioned it to data with not any response at all, I guess they are very busy with other things. there is a small group of serbs who are working on renaming everything back to pre 1989. I guess we will have to deal with this on a daily basis. It is not the first time we had this problem. mike 2012/4/1 Paul Norman penor...@mac.com From: Lester Caine [mailto:les...@lsces.co.uk] Subject: Re: [OSM-talk] Komuna e Malishevës, Serbia ? Mike Dupont wrote: 2012/4/1 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Altin Ukshini wrote: Does anyone care about these reports ? I said it before and I'm saying it again, we can't monitor/administer the map everyday and you know this, we don't even have enough people contributing in OSM here in Kosovo and Serbians are using this opportunity to change whatever they want in the map. I don't think that you might want to loose contributors from Kosovo !? You have to report these violations... how much will this last until someone makes a decision ? We have already reported so many violations till now. If you have reports of vandalism that the local community can't deal with, send them to d...@osmfoundation.org. Include lists of objects and changesets. Without those you can't tell who changed what. 'Location' is somewhat hit or miss everywhere. My own diary postings give some strange textual descriptions of where they were supposed to be located. The problem here is simply that there is no clear mechanism for identifying 'where' a location is, so until all of the relevant boundaries are mapped and tested in the same way as the intensive effort on getting the coastline complete it is going to be difficult to fix some of these irritations. I've given up asking for a proper check on hierarchy place and is_in which would at least get towns in the right country ... rather than relying on the mapped boundaries ... this has changed, it used to be kosovo. it needs to be fixed, please. My point is ... does anybody actually know where it is broken? It is not the 'is_in' tag ... that isn't used to determine location ... last time I tried looking at this problem in the UK nobody seemed to know how the location was ACTUALLY generated :( It looks to the 'administrative boundaries' areas and so presumably someone has been playing with them? It's a pain trying to find what has been 'modified' ... ( No bloody politics here RB !!! ) The best way I've found to debug the location information is to look up the location on http://nominatim.openstreetmap.org For the example diary entry linked, this gives you http://nominatim.openstreetmap.org/details.php?place_id=4568477 This tells you that the place is a place=hamlet node in the boundary=administrative relation Komuna e Malishevës (http://nominatim.openstreetmap.org/details.php?place_id=128946600) Now it gets complicated. The node is within three admin_level=2 or admin_level=3 boundaries. These are: http://www.openstreetmap.org/browse/relation/2088990 with name:en=Kosovo and Metohija admin_level=2 created March 18th http://www.openstreetmap.org/browse/relation/53295 with name:en=Kosovo and Metohija admin_level=2 created 2008. The admin_level started off as 3, was changed to 2 in July 2010 and back to admin_level=3 Feb 2012. The name was also changed from Kosovo to Kosovo and Metohija at the same time (in all languages). http://www.openstreetmap.org/browse/relation/1741311 with name:en=Serbia admin_level=2 created in 2011. Because regenerating all of the address data inside a country would be too much of a performance drain, they are cached for large boundary objects. My guess is what happened is at some point in the past the 53295 relation was broken and Nominatim cached it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline Update
On 1-4-2012 3:40, Paul Norman wrote: Just be careful to not accidentally upload the .osm that indicate the problems. You should modify it to have upload='false' in there. Then JOSM will discourage you from uploading that file. osm version='0.6' upload='false' See http://josm.openstreetmap.de/ticket/4043 -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline Update
- Original Message - From: Steve Bennett stevag...@gmail.com To: Paul Norman penor...@mac.com Cc: talk@openstreetmap.org Sent: Sunday, April 01, 2012 12:58 AM Subject: Re: [OSM-talk] Coastline Update On Sat, Mar 31, 2012 at 2:26 PM, Paul Norman penor...@mac.com wrote: There are no significant multi-square flooded or dry areas. The following areas have significant number of error points: Pudget Sound in Washington State The mouth of the Columbia river in Washington The Eastern Australia coast Speaking as an Eastern Australian coast dweller, what do we need to do? What do the red spots in the map mean, and what do we need to do about them? Steve What do the red dots mean? the red dots represent where there is a possibility of a gap in gap in the OSM coastline ways following the deletion of data which is happening this weekend. This gap could just be a few metres, or the dot could represent the start of a missing section of many 10's (or possibly 100's) of kilometres. In order for Mapnik to render coastline correctly there needs to be a continuos line of coastline ways around all landmasses. Any gaps in the coastline ways will lead to poor rendering. What can we do about this ? The missing sections in the coastline will need to be completed. There are various ways this can be done. In Australia there is the option of: tracing from Bing or AGRI. there is also the possibility of importing data. I did offer on the talk-au [1] list to re-import PGS data (relatively low quality), though I did ask whether it was better to delay and wait until someone had time to reimport ABS data If you are going to add in any coastline data please be aware that the direction it is drawn is very important. It must be drawn so that the sea is on the right hand side of the way. Although it would be possible in the next few days to redraw some coastline using JOSM and store this off line ready to upload when the database comes back on line, my opinion is that it is better now to do nothing until the new database comes back on line in a few days. I am sure that Paul Norman will then regenerate the shapefiles from which the reds dots are derived, and the error maps will be updated to show actual positions where coastline ways are then missing . Regards David [1] http://lists.openstreetmap.org/pipermail/talk-au/2012-March/008957.html Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
01.04.2012, 12:16, "Mike Dupont" jamesmikedup...@googlemail.com:I think we agreed here on the "on the ground rule", kosovo is on the ground the republic of kosovo and not serbia. [...]belgrad is not in fact control of kosovo, kosovo is its own country. Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
We have rules for osm, they are clear. it is the on the ground rule. http://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule On the Ground Rule If the dispute can not be resolved through discussion, then the simple default rule is that whatever name, designation, etc are used by the people on the ground at that location are used in the non-localized tags. So in the case of North Cyprus, this would be the Turkish names. The specific rules are documented at WikiProject_Cyprus#Disputed_place_nameshttp://wiki.openstreetmap.org/wiki/WikiProject_Cyprus#Disputed_place_names . In the case where there are multiple local names, then if the government with effective and sustained control of the area has an official source of names or an official stance on a naming dispute, then that name is default. For instance, Derry-Londonderryhttp://en.wikipedia.org/wiki/Derry-Londonderry_name_dispute . When there is no clear sustained control of an area, such as Kosovohttp://wiki.openstreetmap.org/wiki/WikiProject_Kosovo, special consideration will be needed on a case by case basis. (Kosovo now has independent government, recognised by many other countries, so this is now less relevant.) OpenStreetMap is not a forum for politics, but a means for understanding. Disputes are not to be carried out in the map, but in discussion. Any editor who does not abide by this, and does not respect agreements in the area, or ultimately the on the ground rule, risks losing the right to participate in OpenStreetMap. Contact one of the mediators above if you see this kind of behavior. 2012/4/1 Павел Фомин pavel...@yandex.ru 01.04.2012, 12:16, Mike Dupont jamesmikedup...@googlemail.com: I think we agreed here on the on the ground rule, kosovo is on the ground the republic of kosovo and not serbia. [...] belgrad is not in fact control of kosovo, kosovo is its own country. Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
2012. gada 1. aprīlis 13:01 Павел Фомин pavel...@yandex.ru rakstīja: 01.04.2012, 12:16, Mike Dupont jamesmikedup...@googlemail.com: I think we agreed here on the on the ground rule, kosovo is on the ground the republic of kosovo and not serbia. [...] belgrad is not in fact control of kosovo, kosovo is its own country. Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? Really? What about South Osettia? I have hard time to think that anybody in Russia would dispute that, but it's recognized only by few countries. And I bet there's lot of Georgians who would like to see it mapped as part of Georgia. But while I fully understand them I recognize that South Osettia currently is de facto independent from Georgia. No hard feelings, but what you are pushing is politics. You don't like what you see in the map, fine. But that doesn't change anything. Fact is a fact. Kosovo is de facto country and while it's not fully recognized internationally, chances of that happening is much closer than any other current disputed regions. When by some actions it happens to be reunited by Serbia - let's map it then accordingly. But while it isn't, is just pushing your own agenda and destroying any joy for mapping. I really don't like posting this, I want to avoid any political posturing these days, but please keep such disputes out of this. Map accordingly to the facts, not historical or what feels right basis. Please. Respectfully, Peteris. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
Hello, my last words on this for now : for osm to be useful it needs two things : 1. local dedicated mappers who have local knowlege who feel comfortable and motivated to continue mapping. 2. accurate maps that reflect the names of places there, signs you can see. if you continue to rename everything into Српска ћирилица, you are going to lose both. I can tell you that the team in kosovo is very happy the way it was, and if you start to have a small minority of serbs renaming the prishtina to Приштина you are going to put into jeopardy the progress we have made. Allowing people in kosovo to feel free after so many people, friends and family where murdered see http://en.wikipedia.org/wiki/List_of_massacres_in_the_Kosovo_War is important. If you force the people there to read ћирилица they will just hate you and your map. thanks, mike On Sun, Apr 1, 2012 at 12:15 PM, pec...@gmail.com pec...@gmail.com wrote: 2012. gada 1. aprīlis 13:01 Павел Фомин pavel...@yandex.ru rakstīja: 01.04.2012, 12:16, Mike Dupont jamesmikedup...@googlemail.com: I think we agreed here on the on the ground rule, kosovo is on the ground the republic of kosovo and not serbia. [...] belgrad is not in fact control of kosovo, kosovo is its own country. Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? Really? What about South Osettia? I have hard time to think that anybody in Russia would dispute that, but it's recognized only by few countries. And I bet there's lot of Georgians who would like to see it mapped as part of Georgia. But while I fully understand them I recognize that South Osettia currently is de facto independent from Georgia. No hard feelings, but what you are pushing is politics. You don't like what you see in the map, fine. But that doesn't change anything. Fact is a fact. Kosovo is de facto country and while it's not fully recognized internationally, chances of that happening is much closer than any other current disputed regions. When by some actions it happens to be reunited by Serbia - let's map it then accordingly. But while it isn't, is just pushing your own agenda and destroying any joy for mapping. I really don't like posting this, I want to avoid any political posturing these days, but please keep such disputes out of this. Map accordingly to the facts, not historical or what feels right basis. Please. Respectfully, Peteris. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
The example of Kosovo in the OSM Wiki that you are quoting here has been added your friend Liz, who is in favour of your view. But there exist other views too. As far as on the ground does matter here, the local signs call the border Kosovo Provincial Boundary not country border. The government in Pristina does not have control over all of the territory as you are claiming here. They can enter the north only under protection of KFOR(NATO) and EULEX(EU) Since you are a friend of rules defined by the OSM Wiki. How about this rule For the sake of clarity, only political entities listed on the ISO 3166 standard are to be considered countries. which you can read here http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Afaik, Kosovo has no official ISO code, hence is no country by this definition. (XK is an inoffical code used by some organisations). What country prefix I have to dial when I want to call someone in the country Kosovo? I am not claiming that Kosovo is no country but want to point out, that there are reasons for both views Mike Dupont wrote We have rules for osm, they are clear. it is the on the ground rule. http://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule On the Ground Rule If the dispute can not be resolved through discussion, then the simple default rule is that whatever name, designation, etc are used by the people on the ground at that location are used in the non-localized tags. So in the case of North Cyprus, this would be the Turkish names. The specific rules are documented at WikiProject_Cyprus#Disputed_place_nameslt;http://wiki.openstreetmap.org/wiki/WikiProject_Cyprus#Disputed_place_namesgt; . In the case where there are multiple local names, then if the government with effective and sustained control of the area has an official source of names or an official stance on a naming dispute, then that name is default. For instance, Derry-Londonderrylt;http://en.wikipedia.org/wiki/Derry-Londonderry_name_disputegt; . When there is no clear sustained control of an area, such as Kosovolt;http://wiki.openstreetmap.org/wiki/WikiProject_Kosovogt;, special consideration will be needed on a case by case basis. (Kosovo now has independent government, recognised by many other countries, so this is now less relevant.) OpenStreetMap is not a forum for politics, but a means for understanding. Disputes are not to be carried out in the map, but in discussion. Any editor who does not abide by this, and does not respect agreements in the area, or ultimately the on the ground rule, risks losing the right to participate in OpenStreetMap. Contact one of the mediators above if you see this kind of behavior. 2012/4/1 Павел Фомин lt;pavelfmn@gt; 01.04.2012, 12:16, Mike Dupont lt;jamesmikedupont@gt;: I think we agreed here on the on the ground rule, kosovo is on the ground the republic of kosovo and not serbia. [...] belgrad is not in fact control of kosovo, kosovo is its own country. Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? ___ talk mailing list talk@ http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@ http://lists.openstreetmap.org/listinfo/talk -- View this message in context: http://gis.19327.n5.nabble.com/Komuna-e-Malisheves-Serbia-tp5609351p5610144.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
On Sun, Apr 1, 2012 at 12:29 PM, ThomasB toba0...@yahoo.de wrote: The example of Kosovo in the OSM Wiki that you are quoting here has been added your friend Liz, who is in favour of your view. I am sorry, it was added by mikel before I even started to work on the project. http://wiki.openstreetmap.org/w/index.php?title=Disputesaction=historysubmitdiff=64112oldid=64101 In the case where there are multiple local names, then if the government with effective and sustained control of the area has an official source of names or an official stance on a naming dispute, then that name is default. For instance, [http://en.wikipedia.org/wiki/Derry-Londonderry_name_disputeDerry-Londonderry]When there is no clear sustained control of an area, such as [http://wiki.openstreetmap.org/index.php/WikiProject_Kosovo Kosovo], special consideration will be needed on a case by case basis. Liz added this : (Kosovo now has independent government, recognised by many other countries, so this is now less relevant.) So, really this is going to come down to the question if you want to offend and possibly lose the dedicate team we have built up in kosovo and lose any value for visitors to kosovo to even use the map. I can tell you that in the case of english wikipedia, the serbs have won a bunch of disputes over the naming of things, for example http://en.wikipedia.org/wiki/%C4%90eravica or the listing of all the mountains of kosovo as being in serbia http://en.wikipedia.org/wiki/List_of_mountains_in_Serbia. The result is that people in kosovo cannot hardly be motivated to contribute to the wikipedia and that might be the fate of osm in the future. I have also given up my efforts to even bother with improving wikipedia after being wikihounded and harrased by a user who was left to do that. please can we stop the damage now and get things back to the previous status quo that was working? mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] A personal plea to bot authors
There are a number of automated changes that get made to the OSM database (bots). Some are straightforward (correcting common misspellings), some less so (changing one form of tagging to another, removing incorrect data*, removing single-node ways). Would it be possible to suspend automated changes until a little time after the activities defined here http://blog.osmfoundation.org/2012/03/27/service-schedule-march-april-2012/ are fully complete? When the rebuild has completed (i.e. immediately after to be determined on the linked page), there will be data in a number of areas that will require human intervention (e.g. a way with nodes from a decliner in it removed, or a node with tags contributed by a decliner removed). What remains may well normally trigger an automated change via a bot. In the post-licence-change situation, however, it surely makes sense to give human mappers a chance to assess the situation without having to plough into pre-bot history, at a time when the OSM servers are likely to be busier than ever. So please, no bots until the date announced on 9th April? Cheers, Andy * This may at first glance seem OK, but I came across a problem with exactly this recently. A newbie editor had merged two ways with different layers to create a way with layer 1; 0. The bot changed this to 1 when the correct action would have been to investigate which ways the newbie editor merged and ensure that the correct layer was applied to the correct parts of the new way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Imagery parallax error in high altitude areas
It recently struck me while identifying mountain peaks in the himalayas that something may not be right. All of us have noticed that the top of skyscrapers is off from the base of the building owing to parallax error of the satellite capturing the image at an angle. The average seems to be around a 0.2m displacement for every 1m increase in height (based on calculations made in a couple of cities in India). For an imagery tile which has 1000m variation in elevation, various objects could be displaced by as much as 200m from its real position. This means that tracing mountain roads, streams and peak from imagery would inherit significant parallax error displacement and there is no easy way of accurately offsetting the imagery before tracing either. Has anyone done any analysis on how bad such errors can be? PS: I thought i'd look at the case of Mt Everest, which not surprisingly has been marked using the high res bing imagery. I compared it with the coords on wikipedia and there seems to be a difference of around 50m [1]. I was expecting more displacement, but then again I dont know how accurate the wikipedia coords are, If its based on google imagery, its got some parallax error again. [1] http://www.openstreetmap.org/index.html?mlat=27.988056mlon=86.925278zoom=12layers=B000FTF -- j.mp/ArunGanesh ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] It has begun
On Sun, Apr 1, 2012 at 4:17 AM, Toby Murray toby.mur...@gmail.com wrote: OSM is in read-only mode as of 8:02 UTC. Looking at the minutely replication files, this was the last changeset to upload: http://www.openstreetmap.org/browse/changeset/11173886 Let's all wish the hard working admins good luck. And a thank you for the admins too. Hey, Toby, thank you for your hands-on approach to contacting lost mappers.Do you know haw many you reached and how many responded? Thanks also to Simon Poole, his concept of the lost mappers task force seems to have been really effective. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] A personal plea to bot authors
Hi, On 04/01/2012 02:24 PM, SomeoneElse wrote: Would it be possible to suspend automated changes until a little time after the activities defined here http://blog.osmfoundation.org/2012/03/27/service-schedule-march-april-2012/ are fully complete? Most of these bots violate the automated edits policies anyway and the only reason that they haven't been stopped and held to account is that Data Working Group haven't got the manpower. But we plan to be much stricter on automated edits and imports in the future. * This may at first glance seem OK, but I came across a problem with exactly this recently. A newbie editor had merged two ways with different layers to create a way with layer 1; 0. The bot changed this to 1 when the correct action would have been to investigate which ways the newbie editor merged and ensure that the correct layer was applied to the correct parts of the new way. This is exactly what we would like to stop *generally*, not only just for a while. 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] It has begun
On Sun, Apr 1, 2012 at 10:04 AM, Richard Weait rich...@weait.com wrote: Hey, Toby, thank you for your hands-on approach to contacting lost mappers. Do you know haw many you reached and how many responded? I attempted contact with 168 users. 105 of them accepted the new terms. I got two hostile responses and one user who couldn't find 5 minutes in the month of March to log in and review the new terms. But my efforts pale in comparison to Simon's work. And my 105 responses wouldn't have been anywhere near that without his help and coordination. And thanks to EVERYONE who took a few minutes to send a message to some local users. Without this distributed effort I doubt we would have seen the steady rate of new acceptors as seen on my graphs: http://ni.kwsn.net/~toby/OSM/license_count.html I was really expecting that line to flatten out a while ago. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] It has begun
On 4/1/2012 3:01 PM, Toby Murray wrote: I attempted contact with 168 users. 105 of them accepted the new terms. That's much higher than I would have expected. My stats: Contact about terms via OSM: 8 Response: 0Obviously I used the wrong wording or was unlucky. But I did tailor the message to their home edits. Coincidentally, I've sent 5 OSM contact messages to local mappers over the past 3 years to explore a meetup idea. Zero responses. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
On Sun, Apr 1, 2012 at 3:01 AM, Павел Фомин pavel...@yandex.ru wrote: Arrrgh. We should have rules on mapping disputed areas and partially recognised countries. Is OSM showing the internationally accepted situation or is it taking into account every single front line? Seems to be inconsistent. For example: Scotland and Wales get boundaries, but North American locales with similar sovereignty like the Cherokee Nation and Navajo Nation don't. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] No Data overlay on OpenStreetmap.org
Hi There used to be a Data overlay available on OpenStreetmap.org, it seems that this has been removed or moved somwhere else. I liked the possibility of exploring data by zooming in and turning the data layer on to see tags on stuff, now I have to start potlach editor to see it, and this is even disabled the next days. Is this possibiliy removed or just moved somewhere else ? Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] No Data overlay on OpenStreetmap.org
On 1 Apr 2012, at 22:20, Carsten Nielsen wrote: Hi There used to be a Data overlay available on OpenStreetmap.org, it seems that this has been removed or moved somwhere else. I liked the possibility of exploring data by zooming in and turning the data layer on to see tags on stuff, now I have to start potlach editor to see it, and this is even disabled the next days. Is this possibiliy removed or just moved somewhere else ? It has been moved to the edit tab under the name Browse Map Data. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] No Data overlay on OpenStreetmap.org
It moved to the Edit tab. Hover over the edit tab with your mouse (don't click) and a menu will pop up with the data layer option. IMO it should be moved back to the layer selection. Hovering over the edit tab is about as unintuitive as it gets. Toby On Sun, Apr 1, 2012 at 3:20 PM, Carsten Nielsen list_re...@toensberg.dk wrote: Hi There used to be a Data overlay available on OpenStreetmap.org, it seems that this has been removed or moved somwhere else. I liked the possibility of exploring data by zooming in and turning the data layer on to see tags on stuff, now I have to start potlach editor to see it, and this is even disabled the next days. Is this possibiliy removed or just moved somewhere else ? Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
OSM should not act upon advocacy to declare as fact every wish for independence, especially if ground situation is that authority of the territory is taken by force and in recent past so that matter is not internationally settled. That would mean that any terrorist organization that gain military authority at some territory gets the right to rename all places and declare territory as independent country on OSM? Kosovo as you call it here is actually called Kosovo i Metohija. Status of that territory is quite a hot matter. It is not recognized as an country and by international agreements it is still part of Serbia. Most of the territory is actually owned by people who are killed or expelled out of Kosovo i Metohija. People who survived cannot get back to their property as they will be killed if they do so. That is the real fact, not what Mike Dupont talks. OSM should not act upon claims of unrecognized government of one nation which killed or expelled by brutal force almost all people of all other nations from that territory. Even international tribunal still tries to unmangle what actually happened there. What is now happening on OSM is renaming places in Kosovo i Metohija and giving them names they never had. That territory was populated by mostly Serbian people for centuries. Albanians showed there in recent past and in last decade they are doing all they can to albanize everything claiming not just names, but people, cultural heritage and history. Intentions of the contributors in OSM map of Kosovo i Metohija is best displayed by ignoring the fact that on the ground both Serbian and Albanian languages are used. Serbian language is ignored except for minor number of map objects. Names for lots of objects have been set in many other languages but Serbian. Goal of those contributors is to present Kosovo i Metohija as territory where Serbian people do not live and Serbian language does not exist. OSM should not allow that. OSM should follow international law. If Kosovo i Metohija become independent in the future, then OSM should allow it to be treated as such on maps. What happens now is that OSM is abused for political misinterpretations not just of status of that territory, but on language, culture and population structure. For now, Kosovo i Metohija is part of Serbia and OSM should reflect that, including using historically appropriate names on OSM map. If Albanian contributors from Kosovo i Metohija are threatening to leave OSM, then so be it. If they are prepared to falsify facts and use OSM to crate map as they like it to be, and not what is real, then they should not be allowed to do so anyways. But, it is not matter of Albanian contributors as there are just few of them. Map of Kosovo i Metohija is actually drawn mostly by foreigners like Mike Dupont, who work for their governments (or NGO's) of for the Albanian government and use OSM to advocate political aspirations of their governments. After all it is not on OSM to choose if it will loose Albanian or Serbian contributors (although Serbians did not express blackmail of leaving OSM on this matter). OSM should require facts, following international law and honest contribution in good will. What happens on Kosovo and Metohija map in OSM is very opposite: falsification of facts, against international law, dishonestly and with mean intentions. OSM should stop that, not just on map of Kosovo i Metohija, but in any similar situation. If not, there is high risk that political issues will reflect OSM. OSM is far to open and vulnerable. It will not be able to handle mapping wars if they occur for each and every territory where political authority is questioned. -- View this message in context: http://gis.19327.n5.nabble.com/Komuna-e-Malisheves-Serbia-tp5609351p5611125.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] No Data overlay on OpenStreetmap.org
On Sun, Apr 1, 2012 at 4:46 PM, Toby Murray toby.mur...@gmail.com wrote: It moved to the Edit tab. Hover over the edit tab with your mouse (don't click) and a menu will pop up with the data layer option. IMO it should be moved back to the layer selection. Hovering over the edit tab is about as unintuitive as it gets. iirc from the commit logs, the edit tab is a temporary place for the data layer link as part of the ongoing site improvements. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
Am 2. April 2012 00:31 schrieb Mike mike.cuttl...@gmail.com: OSM should not act upon advocacy to declare as fact every wish for independence, especially if ground situation is that authority of the territory is taken by force and in recent past so that matter is not internationally settled. That would mean that any terrorist organization that gain military authority at some territory gets the right to rename all places and declare territory as independent country on OSM? Kosovo as you call it here is actually called Kosovo i Metohija. Status of that territory is quite a hot matter. It is not recognized as an country and by international agreements it is still part of Serbia. There are 89 countries who recognized Kosovo (e.g. the USA, UK, Germany, France, Italy, Japan, Australia, ...) and it has joined the International Monetary Fund and World Bank. Serbia sought in 2008 an advisory opinion from the International Court of Justice (ICJ) on the legality under international law of Kosovo's declaration of independence. The ICJ released the advisory opinion in July 2010 affirming that Kosovo's declaration of independence did not violate general principles of international law, UN Security Council Resolution 1244, or the Constitutive Framework. The opinion was closely tailored to Kosovo's unique history and circumstances. (from CIA Worldfactbook, https://www.cia.gov/library/publications/the-world-factbook/geos/kv.html ). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
On Mon, Apr 2, 2012 at 12:31 AM, Mike mike.cuttl...@gmail.com wrote: Intentions of the contributors in OSM map of Kosovo i Metohija is best displayed by ignoring the fact that on the ground both Serbian and Albanian languages are used I have done my best to add in the serbian names of all the towns etc. we have had a good working relationship with the serbian team so far. noone is blackmailing here, I am just asking if you want to offend and lose contributors or make the make useless after it has been given names that dont appear. imagine someone who goes to prishtina with a printed osm map with the serbian names and trys to find something, they ask for help and show the map to someone, the people on the ground wont be happy to see a map like that and the tourist wont be happy either. mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Komuna e Malishevs, Serbia ?
On Mon, Apr 2, 2012 at 12:31 AM, Mike mike.cuttl...@gmail.com wrote: OSM should follow international law. There are a great deal of disputes here on this issue I agree, I dont want to even go into them in detail. my question is, do you care about the progress we have made, the community building and the evangalism of osm to the people on the ground who happen to live in this place? We can discuss all day about the legal side of if they have the right to exist, we can discuss all day who was there first. the balkans is full of people who were not there before, at some point all people came to the balkans if you go by some theories, all people originated from africa. So, lets not go into history too much here and stick to the point of making useful maps. I think the most important thing here at the moment is to create an accurate and useful map of the situation on the ground. The best thing is to get local people on the ground to contribute to these maps. We need to try and keep the people who are living in some area and contributing to the maps happy. If the serbs in Gračanicahttp://en.wikipedia.org/wiki/Gra%C4%8Danica,_Kosovo want to name everything cyrillic, it would not bother me, because that would make them feel comfortable contributing to osm. I think we need to work on getting people to contribute here. If Kosovo i Metohija become independent in the future, then OSM should allow it to be treated as such on maps. Well last I checked they are independent, if not by your view point, I dont know when you were there last. I flew in last in nov 11 for the conference we organized there, also to promote openstreetmap http://www.flossk.org/en/blog/sfk11 and it was still independent. I have regular conversations with the team there and they did not tell me that they lost it. In fact I did not see any serbian border guards, serbian signs or anything on my visit, all say republic of kosovo. What happens now is that OSM is abused for political misinterpretations not just of status of that territory, but on language, culture and population structure. Well if we let you get your way, you will render the map useless in that area, you will scare off the people we have attracted so far and then you will be sitting on an out of date copy of your Kosovo i Metohija map with no one to use it or appreciate it, except maybe from outside of kosovo. For now, Kosovo i Metohija is part of Serbia and OSM should reflect that, including using historically appropriate names on OSM map. We are working on that and I have done my best. Also on wikipedia I have tried to include the serbian and albanian names, also the local bosnian and turkish names of things. On the wikipedia we had to fight even for that because in the ideas of the people who are living back in 1988, the other names have no place in greater serbia. There are elements who do not want to allow for people to use thier local names. Now that is the point here, as an outsider and a researcher I am interested in both sides of the story so I can debunk myths on both sides. And in the balkan region, everyone is full of a very personal and subjective history and viewpoint that does not mesh with the others. If Albanian contributors from Kosovo i Metohija are threatening to leave OSM, then so be it. they are not threatening, I am warning you that it will be very hard to continue my work in improving the map there and teambuilding if some reckless people continue to renaming everyhing and try and roll back the clock to 1988. If they are prepared to falsify facts and use OSM to crate map as they like it to be, and not what is real, then they should not be allowed to do so anyways. Lets talk about that on a point by point basis, before we started on this project the map in kosovo was really not even worth mentioning. now even the serbian team is waking up and becoming active, I think that is good. The best thing would be to get the local people all over the balkans to work on their little bit of the map where they live and they feel comfortable. There are little enclaves of an ancient greek colony for example in narte http://www.openstreetmap.org/?lat=40.49762lon=19.45587zoom=17layers=M, now it would not bother me if the people who lived there would include the local names of things as they are written down or how they call them. But, it is not matter of Albanian contributors as there are just few of them. Lets look at the people who have been working on prishtina for example, prizren. Map of Kosovo i Metohija is actually drawn mostly by foreigners like Mike Dupont, who work for their governments (or NGO's) of for the Albanian government and use OSM to advocate political aspirations of their governments. Wait and please stop right there. the NGO that I founded, flossk.org is a totally independant and private thing. I do not work for it, I get no salary. I do not work for any government whatsoever. I dont know where you
Re: [Talk-is] Ég sendi skilaboð á þá sem ekki hafa enn samþykkt Contributor Terms
Viðbrögðin voru góð, þeir sem ekki samþykktu eru merktir gulir: http://odbl.de/iceland.html. Ég sendi skilaboðin gegnum skilaboðakerfið. kv. Björgvin On Thu, Mar 29, 2012 at 2:01 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: 2012/3/26 Björgvin Ragnarsson nifgr...@gmail.com: Listann yfir notendur fann ég hér: http://odbl.poole.ch/iceland-20120213-20120321-poly.html þið þurfið því ekki að ónáða þá líka, Hvernig gekk þetta? Ég býst við að þú eigir við í gegnum OSM skilaboðakerfið, ég er með upplýsingar um aðrar leiðir til að hafa samband við nokkra af þessum notendum. ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is
Re: [Talk-de] OSM dieses Jahr im Heise Aprilscherz
Am 01.04.2012 04:00, schrieb Garry: Am 01.04.2012 01:28, schrieb Roland Ramthun: Hallo Leute, wir sind dieses Jahr im Heise online Aprilscherz zu finden: http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html Wenn DAS mal nicht der endgültige Beweis ist, das wir mittlerweile Mainstream sind, oder so... Mir gefällt der Aprilscherz nicht - für den flüchtigen Leser ist das eine negative Werbung für OSM. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Sehe ich genauso. Macht den Eindruck, als würde die gesamte Community in der Cleanmap die halbe Hauptstadt übersehen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Krisenmapping Westberlin - Mapping Party?
Hätte man denn nicht wenigstens einen auch existierenden OSM-Usernamen nehmen können? Dann wäre es wenigstens halbwegs glaubhaft...aber die Idee für den Aprilscherz an sich ist nicht schlecht. @Garry: Noch wurden keine Daten von der OSMF als ODbL bereit gestellt, ergo fehlt ein HInweis auf cc-by-sa ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmanipulation wegen Lizenzwechsel
On Sun, Apr 01, 2012 at 04:24:46AM +0200, Garry wrote: Am 31.03.2012 11:21, schrieb malenki: Rechtlich ist es vermutlich bis zur Freigabe eine Baustelle - könnte mir vorstellen dass es versicherungstechnisch einen Unterschied macht ob ich eine Baustelle oder eine nur gesperrte Strasse befahre. Die Freigabe für den Verkehr und die Einweihung (Durchschneiden von Bändchen usw.) sind rechtlich völlig verschiedene Dinge. Die Freigabe für den Verkehr ist das was der Name sagt: die Straße darf offiziell befahren werden, sie ist keine Baustelle oder gesperrte Straße mehr. Die Einweihung ist ein Festakt mit Bändchen zerschnippeln, Schnittchen usw. ohne rechtliche Relevanz. flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sicherheitsrisiko für Deutschland durch ODBL-Umstellung
Hallo, in diesem Artikel wird auf Navigationsprobleme durch den Wechsel zur ODBL hingewiesen: http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html Insider wissen aber das durch die beschriebene Löschung viel weiter reichende Probleme zu erwarten sind. Es besteht eine massive Sicherheitsproblematik für Deutschland. Angela Merkel wird die Minister ins Kanzleramt berufen. Im Innenministerium, Aussenministerium, Verteidigungsministerium, bei Bundeswehr und Bundesgrenzschutz werden Krisenstäbe gebildet. Zu lange hat man dort und bei anderen staatlichen Stellen die Problematik der ODBL-Umstellung unterschätzt. Durch die Löschung der OSM-Beiträge von Nutzern wie Pillarpair und vielen anderen werden sicherheitsrelevante Daten nicht mehr verfügbar sein. Es gibt jetzt keine Möglichkeiten mehr diese Daten aus OSM zu ziehen und damit eine Verpixelung sicherheitsrelevanter Gebiete bei Bing und anderen Anbietern von Luftbildern zu erzwingen. Besonders kritisch wird die Situation dadurch, dass fehlende Daten gerade jetzt durch den READ-ONLY-Status der Datenbank nicht so schnell wie bei OSM gewohnt behoben werden können. Harald black_bike -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osmarender Auswahl immer noch in OSM Karten
Hallo Alle, In der Karte: http://www.openstreetmap.de/karte.html und http://openpistemap.org/ steht immer noch Osmarender zur Auswahl, obwohl es das nicht mehr gibt. Den Webmaster von openstreetmap.de habe ich vor einigen Tagen dazu angeschrieben. Leider bisher ohne Antwort. Vielleicht liest ja der eine oder andere für OSM Karten Zuständige hier mit und nimmt das zum Anlass seine Karte zu aktualisieren. Gruss ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM dieses Jahr im Heise Aprilscherz
Am 01.04.2012 04:00, schrieb Garry: Mir gefällt der Aprilscherz nicht - für den flüchtigen Leser ist das eine negative Werbung für OSM. Da würde ich mich nun wirklich nicht drüber beschweren. Schließlich hätte man praktisch denselben Artikel auch in ernst schreiben können. Ersetze Berlin - Warschau, Pillarpair - balrog-kun, beispielsweise. Freuen wir uns lieber darüber, dass OSM inzwischen bekannt genug ist, um für einen Aprilscherz herzuhalten. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender Auswahl immer noch in OSM Karten
Hallo Lothar, Am 1. April 2012 11:57 schrieb lothar.b...@t-online.de: Hallo Alle, In der Karte: http://www.openstreetmap.de/karte.html und http://openpistemap.org/ steht immer noch Osmarender zur Auswahl, obwohl es das nicht mehr gibt. Den Webmaster von openstreetmap.de habe ich vor einigen Tagen dazu angeschrieben. Leider bisher ohne Antwort. Sorry, bei uns ist keine Nachricht angekommen. Aber danke für den Hinweis, ich habe den Osmarender Layer in der Karte entfernt. Grüße, Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei Fragen zum OpenLayers-Api
Wolfgang Wienke wrote: Kennt jemand ein Forum zu diesem Thema? Die Resonanz auf eine Frage hier war gering. Foren zu dem Thema kenne ich nicht. Zudem meide ich Foren wo möglich. Ich war der Meinung, dass deine Frage durchaus beantwortet wurde. Es kam von deiner Seite ja keine weitere Rückfrage mehr. Ich würde vorschlagen, du zeigst erstmal Eigeninitiative und baust mal einen ersten Test auf, hostest das irgendwo und postest dann bei einer weiteren Rückfrage einen Link zu deiner Karte. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz 89 25.3.- 31.3.
Hallo, die neue Wochennotiz Nr. 89 mit allen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/2012/04/wochennotiz-nr-89/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sicherheitsrisiko für Deutschland durch ODBL-Umstellung
Harald Schwarz harald.malte.schw...@gmx.de wrote: in diesem Artikel wird auf Navigationsprobleme durch den Wechsel zur ODBL hingewiesen: http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html Schau mal aufs Datum! Berlin wurde initial im wesentlichen fast vollständig von zwei Leuten erfasst nämlich von Sascha Pomplun (User:Toaster) und Frank Gründer (User:Elwood). Beide haben der ODBL zugestimmt. Gruss Sven -- Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der Demokraten (Theodor W. Adorno) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei Fragen zum OpenLayers-Api
Hallo! Am 01.04.2012 13:22, schrieb Manuel Reimer: Wolfgang Wienke wrote: Kennt jemand ein Forum zu diesem Thema? Die Resonanz auf eine Frage hier war gering. Foren zu dem Thema kenne ich nicht. Zudem meide ich Foren wo möglich. Ich war der Meinung, dass deine Frage durchaus beantwortet wurde. Es kam von deiner Seite ja keine weitere Rückfrage mehr. Ich hatte mich wohl falsch ausgedrückt. Ich suche eine Lösung nicht direkt über das OSM-Api, sondern mit OpenLayers. Ich würde vorschlagen, du zeigst erstmal Eigeninitiative und baust mal einen ersten Test auf, hostest das irgendwo und postest dann bei einer weiteren Rückfrage einen Link zu deiner Karte. Ich habe mir natürlich alle möglichen Hilfeseiten bzw. die Beispiele dort angeschaut, aber keine Lösung hat funktioniert, wenn ich Sie auf mein Problem übertragen habe (Text allein, Marker mit Text, VektorLayer mit Text, Imagelayer und Text als Bilddatei). Vielleicht liegt es daran, dass ich den Text über einer einer Google-Map ausgeben möchte (andere Projektion?). Ich habe mal das Simpel-Beispiel unter http://www.aachen-hat-energie.de/test_ww/OSM-text.htm gestellt. Wäre nett, wenn jemand hilft. -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sicherheitsrisiko für Deutschland durch ODBL-Umstellung
Am 1. April 2012 17:53 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Schau mal aufs Datum! Ich bin mir sicher, dass da aufs Datum geschaut wurde... Nicht so sicher bin ich mir, dass Du, Sven, den Beitrag auch gelesen hast... ;-) Weiter noch 'nen schönen ersten... LG Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmanipulation wegen Lizenzwechsel
am Freitag, 30. März 2012 um 21:11 schrieb Robert S.: Ich bin gerade eben auf folgendes Changeset gestoßen: Es handelt sich dabei um einen Autobahnneubau, der erst am 4.4 eingeweiht wird (mit Minister und so...) und dort von dem Benutzer jetzt schon als fertig eingetragen wurde. Anscheinend, weil er diesen fertigen Abschnitt noch in den letzten CC-BY-SA-Datenbankauszügen sehen will. Ist das ein akzeptiertes oder zumindest geduldetes Verhalten? Ist doch OK, damit ist OSM zeitlich wohl weit näher dran als die meisten anderen Kartenanbieter. Die haben Neubauten schon Monate vorher oder erst Jahre später drin. Dazu kommt, dass die Daten in der jetzigen Form eine ziemlich miserable Qualität haben. Anscheinen hat der Nutzer einfach highway=construction mit highway=motorway ersetzt. Darauf gestoßen bin ich, weil ich mir die Baustelle am 1.4 selber anschauen Dann kannst Du es ja verbessern. will. Da ist es natürlich blöd, wenn man absichtlich verfälschtes Kartenmaterial hat. Warum verfälscht? Wann wäre der Eintrag denn OK? Ich der Sekunde, wo das Band offiziell durchgeschnitten wird? Macht das einer? Vielleicht trägt das ein Nutzer aber erst am Abend oder einige Tage später nach; dann haben wir genauso falsche Daten. Ich verstehe die ganze Aufregung nicht. Nur weil im Kommentar jemand was zum Lizenzwechsel reingeschrieben hat? Na und, laß ihn doch. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmanipulation wegen Lizenzwechsel
Nach meiner Meinung ist eine Straße fertig, wenn alle Bauarbeiten beendet sind (unabhängig von einer eventuellen Einweihung). Danach bestehen höchstens noch Nutzungsbeschränkungen, die in die access-tags aufgenommen werden. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmanipulation wegen Lizenzwechsel
P.S. Verwerflich finde ich die Leute, die die neue Lizenz abgelehnt haben (aus rein persönlichen Gründen, nicht wegen Import o.Ä.), sich dann aber einen Zweitaccount angelegt haben (wo man natürlich automatisch die neuen CTs akzeptieren mußte) um weitermappen zu können. Eine entsprechende Person hat dann tatsächlich im Forum noch angefragt, wie er dann sein CC-Planet-Dump später lokal Ergänzungen hinzufügen kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmanipulation wegen Lizenzwechsel
Am 01.04.2012 19:59, schrieb Christian H. Bruhn: Ist doch OK, damit ist OSM zeitlich wohl weit näher dran als die meisten anderen Kartenanbieter. Die haben Neubauten schon Monate vorher oder erst Jahre später drin. Ich find's nicht ok, aber da hat jeder halt seine eigene Schmerzgrenze. Warum verfälscht? Wann wäre der Eintrag denn OK? In der Sekunde, wo das Band offiziell durchgeschnitten wird? Macht das einer? Ja, ich. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ÖPNV-Relationen in OSM
Moin, ich habe schon viele Stunden Arbeit in die Erstellung und Pflege von ÖPNV-Relationen (Bus-, Bahn- und Fährlinien) investiert. Leider ist der Erfolg meiner Bemühungen (und der vieler anderer Mapper) gering. Die Relationen beschreiben entweder nur eine Richtung einer Linie, beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in einer Relation. Die Straßensegmente sind (teilweise falsch) mit role-Tag forward/backward, manchmal mit route, default, alternate etc. versehen. stop_position- und platform-Punkte haben role-Tags , stop, platform aber auch stop:22 oder platform:60:alternate:1. Die Haltestellen sind teils zwischen den ways, oft auch unsortiert am Ende. name-Tags sind fast immer willkürliche Textfolgen aus ref/operator/network/direction. from und to fehlen teilweise oder sind uneinheitlich gebildet. Einzig die Liniennummer ist eindeutig im ref-Tag enthalten. Viele Relationen sind durch spätere Bearbeitung der ways beschädigt. Die Daten reichen aus, um eine Karte mit Liniennummern an Straßen und Haltestellen zu erzeugen. Unsortierte Relationselemente, unsinnige role-Angaben und kleine Lücken erzeugen allenfalls kleine Kartenfehler, die der menschliche Betrachter meist ignorieren kann. Für solche ÖPNV-Karten würde aber auch ein einfaches lines-Tag am way bzw. an der Haltestelle genügen. Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging- Varianten machen es unmöglich, die Daten korrekt zu interpretieren. Bei vielen Relationen ist nicht erkennbar, ob zwei Haltestellen vom selben Bus angefahren werden oder ob sie zu zwei alternativ bedienten Teilstrecken gehören. Ein großer Teil der Relationen ist fehlerhaft. Selbst wenn eine Relationen eine unverzweigte Strecke abbildet und keine Fehler hat, kann man die Angaben nicht zur Fahrtplanung nutzen, da keine Informationen zu Betriebszeiten, Takt oder Fahrzeiten bietet. Viele gedruckte Reiseführer enthalten dagegen grobe Informationen wie bis Ziel ca. 70 Min., Mo-Sa 6-22Uhr, So 8-20Uhr, tagsüber alle 15 Minuten, nach 18Uhr alle 30 Min., die auch Jahre nach dem Druckdatum noch nützlich sind. Solche Informationen wären auch in OSM möglich. Leider können sich die relativ großen Relationen des ÖPNV auch unmittelbar störend auswirken. Wenn eine Straße Teil mehrerer Relationen ist, überlege ich es mir oft zweimal, ob ich in wenigen Minuten eine Verbesserung der Straßendaten mache und dann ein Vielfaches der Zeit in die Überprüfung und Anpassung der Relationen stecken muss. Ein OSM-Neuling wird sich oft gar nicht herantrauen. Wenn man etwas an Relationen geändert hat, ist immer ein Konflikt beim Upload möglich, der von vielen Mappern nicht korrekt gelöst werden kann. Mehrere Streckenvarianten der Buslinie sich durch Kopieren und Ändern der ersten Relation leicht erstellt, aber müssen danach einzeln gepflegt werden. Die Qualität der ÖPNV-Relationen hat sich nach meiner Einschätzung in den letzten zwei Jahren nicht gebessert. Die Zahl der Tagging-Varianten ist gestiegen, die Fehlerquote ist unverändert hoch. Es erscheint mir sinnlos, wie bisher weiterzumachen. Ich habe nur vage Ideen, wie das Problem zu lösen wäre: - eine Editorerweiterung, die defekte Routen erkennt und die langweilige Arbeit bei der Erstellung/Reparatur deutlich vereinfacht (für JOSM wäre das mit viel Programmierarbeit vielleicht möglich, aber bei anderen Editoren?) - ein Bot, der jede Nacht die unterbrochenen Relationen repariert, die role-Tags richtig setzt und nicht automatisch korrigierbare Relationen meldet (auch sehr schwierig umzusetzen). Die Mapper könnten unbelastet editieren :-) Beide Varianten wären mit einer Vereinheitlichung des Relationsschemas auf das vom Programm unterstützte Format verbunden. - Umstellung auf ein stark vereinfachtes Relationsschema, bei dem nur die Haltepunkte, aber nicht die Stecken Elemente der Relation sind. Solche Relationen wären viel einfachen zu erstellen, zu pflegen und viel robuster gegen Änderungen am Wegenetz, aber es wäre zur Kartenerstellung eine neue Nachbearbeitung mit Routingalgorithmen nötig (dieses Schema hat schon ein anderer vorgeschlagen, ich finde die Referenz aber gerade nicht). Bei allen Varianten könnte man Tags für Betriebszeiten (operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn möglich eine URL des Fahrplans (url:timetable?) hinzufügen. oder - Verzicht auf gerichtete ÖPNV-Linien in OSM. Dann genügt eine leicht zu pflegende Tag-basierte Lösung um Liniennummern mit Haltestellen und Fahrstrecken zu verbinden. Gegebenenfalls Zusammenarbeit mit einem anderen Projekt für ÖPNV. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei Fragen zum OpenLayers-Api
Wolfgang Wienke wo_wienke at gmx.net writes: Ich habe mir natürlich alle möglichen Hilfeseiten bzw. die Beispiele dort angeschaut, aber keine Lösung hat funktioniert, wenn ich Sie auf mein Problem übertragen habe (Text allein, Marker mit Text, VektorLayer mit Text, Imagelayer und Text als Bilddatei). Vielleicht liegt es daran, dass ich den Text über einer einer Google-Map ausgeben möchte (andere Projektion?). Daran wird es nicht liegen. Allerdings muss dann, wenn du schon in einer OSM-Liste fragst, auch die Frage erlaubt sein, warum du keine OSM-Karte verwenden willst. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei Fragen zum OpenLayers-Api
hi wolfgang, das ist zwar eine gui zur openlayers-liste, aber du musst dich dennoch bei deren liste registrieren. solange du in nabble die meldung This post has NOT been accepted by the mailing list yet. siehst, ist die anfrage nicht bei openlayers angekommen. gruss walter nach dem registrieren anfrage neu senden. -- View this message in context: http://gis.19327.n5.nabble.com/Hilfe-bei-Fragen-zum-OpenLayers-Api-tp5608454p5611560.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Cambio Licenza, Utenti non raggiungibili (Email bouncing)
Ho provato a scrivere all'utente Riccardo Ricci, ma ancora non ho avuto risposta, se qualcuno lo conoscesse che lo contatti, altrimenti andrebbero persi non pochi dati a Roma :) -- View this message in context: http://gis.19327.n5.nabble.com/Cambio-Licenza-Utenti-non-raggiungibili-Email-bouncing-tp5600156p5611239.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-lt] OSM tik skaitymo režime
Sveiki OSM jau perjungtas į „tik skaitymo“ režimą (t.y. negalima keisti duomenų). Šiuo metu migruojami duomenys į naują serverį ir (jei neklystu) tuo pačiu dalinai išimami su nauja licencija nesuderinami duomenys. Šitas procesas pagal dabartinį planą baigtis turėtų balandžio 4 ryte. -- Tomas Straupis ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
[Talk-at] ein loch in deutschland
http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html ;-) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ein loch in deutschland
Am 2012-04-01 15:08, schrieb Rainer Fügenstein: http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html Sind spannende Passagen in dem Artikel, z.B.: Aus diesem Grund hat sich der Senat von Berlin bereits mit dem Problem beschäftigt. An verschiedenen Orten, die genau an die Bereiche mit dem bald fehlenden Kartenmaterial angrenzen, werden kurzfristig temporäre Schilder aufgestellt. Hier werden teilweise große Behinderungen erwartet, weil Navigationssysteme ihren Dienst einstellen. Die Schilder (die in deutsch, englisch, französisch und russisch gehalten sind) weisen die Verkehrsteilnehmer deswegen darauf hin, dass sie das von OpenStreetMap abgedeckte Gebiet verlassen. Sie sollen deswegen auf die Beschilderung vor Ort achten und die Aussagen der Geräte ignorieren Mir war nicht klar dass OSM schon so wichtig ist dass sich sogar ein Senat um die Lösung von solchen Problemen kümmert. LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ein loch in deutschland
Schönen guten Tag! Heute (1. April) um 17:22 meinte Stefan Taferner: Am 2012-04-01 15:08, schrieb Rainer Fügenstein: http://www.heise.de/newsticker/meldung/OSM-Lizenzwechsel-reisst-Loecher-in-die-Hauptstadt-1486457.html Sind spannende Passagen in dem Artikel, z.B.: Aus diesem Grund hat sich der Senat von Berlin bereits mit dem Problem beschäftigt. An verschiedenen Orten, die genau an die Bereiche mit dem bald fehlenden Kartenmaterial angrenzen, werden kurzfristig temporäre Schilder aufgestellt. Hier werden teilweise große Behinderungen erwartet, weil Navigationssysteme ihren Dienst einstellen. Die Schilder (die in deutsch, englisch, französisch und russisch gehalten sind) weisen die Verkehrsteilnehmer deswegen darauf hin, dass sie das von OpenStreetMap abgedeckte Gebiet verlassen. Sie sollen deswegen auf die Beschilderung vor Ort achten und die Aussagen der Geräte ignorieren Mir war nicht klar dass OSM schon so wichtig ist dass sich sogar ein Senat um die Lösung von solchen Problemen kümmert. Heute ist was für ein Tag? Richtig, der 1. April, und er Passus mit den Schildern Hier verlassen sie das Gebiet von OpenStreetMap erinnert nun doch zu stark an die damaligen Zonengrenzen-Schilder (wortgleich), um wirklich wahr zu sein. -- Liebe Grüße, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Google Maps Mission
Servus! Hat schon jemand die neue Missionsansicht von Google Maps ausprobiert? Einfach auf maps.google.at klicken und in der rechten oberen Ecke Mission auswählen. MfG ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Google Maps Mission
Haha, ja, gesehen und für epic befunden :) Hab mir gleich gedacht: Hei, mit Mapnik wär das ja auch kein Problem. wär auch mal eine nette Idee, die Power von Mapnik darzustellen... Am 1. April 2012 18:44 schrieb Fabjan Sukalia fsuka...@gmail.com: Servus! Hat schon jemand die neue Missionsansicht von Google Maps ausprobiert? Einfach auf maps.google.at klicken und in der rechten oberen Ecke Mission auswählen. MfG ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- Lukas Bischof p: +43 (664) 416 84 34 w: http://www.wordy-rappinghood.net/ @: lukas.bisc...@gmail.com ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Google Maps Mission
Hallo! On 01/04/12 23:19, Lukas Bischof wrote: Hab mir gleich gedacht: Hei, mit Mapnik wär das ja auch kein Problem. wär auch mal eine nette Idee, die Power von Mapnik darzustellen... Sowas gabs schon mal mit OSM-Daten: http://8bitcity.com/map?Berlin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk-fr] 1099422316.50378
1099422316.50378 ? Oui 1099422316.50378m de high en France métropolitaine dans OSM CC-by-SA. Cela veut dire qu'on a passé le cap des 1 million de kilomètres de routes et chemins ! Requête à refaire dans quelques jours en fois passé en ODbL... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Bonjour, Donc, OSM change de licence, et FOSM évidement pas. Jusqu’à maintenant, toute contribution à OSM se répercutait dans FOSM comme dans n'importe quelle site miroir. Mais, OSM et FOSM sont désormais distincts à partir du 1er avril 2012. (fork d'où le titre) La nouvelle licence Odbl autorise t'elle FOSM à répercuter les contributions OSM (à supposer que cela soit dans leurs intentions) ? L'inverse est de toute évidence non puisque OSM élimine toutes les contributions CC by SA strict. J'arrive donc a la question qui fâche : Si je veux que mes contributions profitent aux deux projets, est il pertinent d'uploader les mêmes objets sur les deux projets ? Y a t'il (Y aura t'il) un moyen d'éviter cette contrainte ? Bon Appétit. -- View this message in context: http://gis.19327.n5.nabble.com/4-jours-pour-digerer-le-coup-de-fourchette-tp5610210p5610210.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Ce n'est pas lié directement au changement de licence (qui était déjà en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au nettoyage des données (qui aura lieu après le redémarrage du service, en tâche de fond), mais lié à un changement de serveur. Malgré tout, un changement de serveur de base de données aurait pu avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne comprends pas la nécessité d'arrêter le service pendant 4 jours, alors qu'une solution de réplication aurait pu être utilisée, même si elle prenait du temps pour tout resynchroniser, sans même arrêter le service. Je comprends la nécessité de passer à un serveur plus puissant. Pas celle d'arrêter le service pendant 4 jours. Cela donne l'impresion forte que le service n'est pas solide et tehniquement pas au point. Au lieu de charger le nouveau serveur pendant 4 jours, il aurait peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt (avec juste un lag time de quelques minutes, vite rattrapé quand l'ancien serveur a arrêté d'accepter les nouvelles données), et ensuite il n'aurait fallu qu'une interruption de quelques minutes pour faire la bascule du nouveau serveur miroir en tant que serveur principal, le temps de reconfigurer routeurs parefeux ou adresses IP et redémarrer les serveurs. L'ancien servant alors de serveur de secours ou pour héberger des services hors-ligne tels que des l'exécution de certains scripts de maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, ou l'exécution de tâches comme la génération et la compression des dumps, ou encore pour augmenter la charge utile de certaines API. Bref le projet a besoin depuis longtemps de développer une solution de réplication en ligne, et cette solution n'a pas été développée. La solution de l'arrêt complet c'est la solution de facilité mais elle nuit au projet. De meˆme la bses de données aurait pu être splittée en plusieurs parties, par secteur angulaire, un serveur frontal collectant les données de l'un ou l'autre pour les accès en lecture (avec un minimum d'objets stocké dans les deux quand il y a des références mutuelles, pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au delà d'une certaine tranche d'identifiants, chacun puisse générer ses propres identifiants uniques dans des blocs de numéros préalloués pour chacun d'eux. Si à la prpchaine panne du serveur il faut encore 4 jours pour remonter un autre serveur, c'est que le projet n'est pas assez solide. La réplication avec consolidation aurait du être en place depuis longtemps, vu la taille du projet. Le 1 avril 2012 11:03, Christian Quest cqu...@openstreetmap.fr a écrit : Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Bonjour, Je rejoins Philippe sur l'importance mondiale qu'a prit le projet OSM. Il serait temps de définir une politique accompagnée de ses moyens techniques pour être à la hauteur de toutes ces contributions qui font d'OSM un fabuleux projet mondial. Un genre d'architecture distribuée semble la voix à explorer. Mes 2 centimes de techos Cyrille. Le 1 avril 2012 17:22, Philippe Verdy verd...@wanadoo.fr a écrit : Ce n'est pas lié directement au changement de licence (qui était déjà en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au nettoyage des données (qui aura lieu après le redémarrage du service, en tâche de fond), mais lié à un changement de serveur. Malgré tout, un changement de serveur de base de données aurait pu avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne comprends pas la nécessité d'arrêter le service pendant 4 jours, alors qu'une solution de réplication aurait pu être utilisée, même si elle prenait du temps pour tout resynchroniser, sans même arrêter le service. Je comprends la nécessité de passer à un serveur plus puissant. Pas celle d'arrêter le service pendant 4 jours. Cela donne l'impresion forte que le service n'est pas solide et tehniquement pas au point. Au lieu de charger le nouveau serveur pendant 4 jours, il aurait peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt (avec juste un lag time de quelques minutes, vite rattrapé quand l'ancien serveur a arrêté d'accepter les nouvelles données), et ensuite il n'aurait fallu qu'une interruption de quelques minutes pour faire la bascule du nouveau serveur miroir en tant que serveur principal, le temps de reconfigurer routeurs parefeux ou adresses IP et redémarrer les serveurs. L'ancien servant alors de serveur de secours ou pour héberger des services hors-ligne tels que des l'exécution de certains scripts de maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, ou l'exécution de tâches comme la génération et la compression des dumps, ou encore pour augmenter la charge utile de certaines API. Bref le projet a besoin depuis longtemps de développer une solution de réplication en ligne, et cette solution n'a pas été développée. La solution de l'arrêt complet c'est la solution de facilité mais elle nuit au projet. De meˆme la bses de données aurait pu être splittée en plusieurs parties, par secteur angulaire, un serveur frontal collectant les données de l'un ou l'autre pour les accès en lecture (avec un minimum d'objets stocké dans les deux quand il y a des références mutuelles, pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au delà d'une certaine tranche d'identifiants, chacun puisse générer ses propres identifiants uniques dans des blocs de numéros préalloués pour chacun d'eux. Si à la prpchaine panne du serveur il faut encore 4 jours pour remonter un autre serveur, c'est que le projet n'est pas assez solide. La réplication avec consolidation aurait du être en place depuis longtemps, vu la taille du projet. Le 1 avril 2012 11:03, Christian Quest cqu...@openstreetmap.fr a écrit : Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
puisque tu semble si sur de ce que tu avances... pourquoi tu ne leur proposerait pas tes services pour améliorer leurs services? Il faut pas oublier que c'est un projet soutenu par une fondation et non pas par une ENTREPRISE! Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! pensez plutot que si se projet n'etait pas en place, de nombreux contributeurs auraient pu se rabattre sur Googlemapmaker à défaut d'un projet libre... -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610440.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 17:43, PierreV belett...@hotmail.fr a écrit : puisque tu semble si sur de ce que tu avances... pourquoi tu ne leur proposerait pas tes services pour améliorer leurs services? Il faut pas oublier que c'est un projet soutenu par une fondation et non pas par une ENTREPRISE! Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! pensez plutot que si se projet n'etait pas en place, de nombreux contributeurs auraient pu se rabattre sur Googlemapmaker à défaut d'un projet libre... Oui aussi ! Ca n'empêche pas de commencer à travailler sur la conception d'une architecture distribuée. Je ne connais pas les coulisses du projet, mais en pensant aux beaux serveurs et à la bande passante gracieusement offerte à l'asso OSM_FR, en se pensant qu'il en est probablement pareil ailleurs, je me dis que l'on pourrait améliorer la puissance technique tout en restant libre. C. -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610440.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 17:43, PierreV belett...@hotmail.fr a écrit : Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! La question du volume est hors de propos. Même pour copier plusieurs téraoctets, il ne faut pas 4 jours, (surtout avec les disques actuels puisqu'il s'agit d'installer un *nouveau* serveur tout neuf, et à rpriori plus performant encore que l'ancien). 4 jours c'est veaucoup trop long pour un service qui a pris une importance mondiale. Et faire tout dépendre techniquement d'un seul serveur, c'est suicidaire. La réplication n'est plus un luxe et aurait du être une priorité depuis longtemps (avant même le changement de licence, qui ne se fera que sur le nouveau serveur parce que les outils pour faire la migration demanderont de la performance et de l'espace de stockage, et beaucoup de travail). Aussi je comprend tout à fait qu'il ait fallu attendre un an pour changer la licence et faire la migration des données puisque l'ancien serveur n'aurait jamais tenu la charge (il avait déjà bien du mal à suivre avec juste les mises à jour actuelles des utilisateurs). Donc Ok pour le fait de démarrer le changement de licence seulement maintenant. Mais en revanche je suis très critique sur les moyens et solutions mis en œuvre pour *seulement* ne faire que changer de serveur. Techniquement il y a un problème sérieux, et si FOSM parvient lui à démarrer dès le début en partant de rien pour charger toute la base OSM, je ne comprends pas que la Fondation, bien plus riche, n'a pas pu ou su monter aussi un autre serveur et le monter en charge jusqu'à ce que son lag soit rattrapé, afin de n'arrêter le service que quelques minutes lors du basculement entre le serveur principal et le miroir. En plus je trouve cet arrêt très risqué. Qui dit qu'il n'y aura pas d'incident de migration et que cela ne prendra finalement pas plus de 4 jours ? En montant un serveur en parallèle jusqu'à ce qu'il ait réussie à tout charger, le risque d'échec restait gérable: on pouvait recommencer en cas de problème sans même rien arrêter du tout, l'échec de migration restait invisible. J'espère qu'il n'est pas question de prolonger ces 4 jours, et que dès que le nouveau serveur sera opérationnel il sera mis en ligne même si c'est avant. Mais en cas d'échec, hors de question de recommencer : on redémarre l'ancien serveur aussitôt et on va chercher à régler le problème de chargement du nouveau serveur. Je crois qu'il est incroyable d'avoir du faire un arrêt aussi long, qui était parfaitement **évitable **donc **inutile**. Et pas question d'accepter alors un nouvel arrêt de 4 jours pour recommencer en cas d'échec de la première migration de données ! OK le projet est libre mais il a aussi des responsabilités à assumer pour obtenir la confiance des contributeurs. Et certes le changement de licence était annoncé, mais PAS un arrêt total du service pendant 4 jours intervenu à la dernière minute uniquement par suite d'une *décision* (mal justifiée techniquement) et pas du tout à cause d'un incident imprévu. Il n'y avait strictement aucun besoin d'une telle précipitation: monter un nouveau serveur et le rendre opérationnel et synchornisé aurait pu se faire pendant 15 jours ou même un mois, comme l'ont fait d'autres (par exemple FOSM). Cette précipitation sur un projet de cette taille non seulement fait courrir un risque élevé pour un projet aussi important, mais justement au vu de la taille des données, ce risque d'incident (normalement réparable) ou contournable) est presque inévitable. Cette précipitation génère un stress de travail énorme sur ceux chargés de monter et maintenir les systèmes, il met en péril l'intégrité des données de façon plus importante (et il sera même impossible d'en discuter ou de trouver des contournements intelligents de certains problèmes techniques qu'OSM est incapable de prévoir, car ils sont imprévus mais surviendront avec une quasi-certitude). Bref je trouve qu'OSM a joué à la roulette russe dans l'histoire et n'est pas à la hauteur de ses responsabilités. Car cette planifiication surprise du changement de serveur, qui a pris de court tout le monde, est réellement un désastre techniquement et pour l'image d'OSM (indépendamment du changement de licence avec lequel OSM a essayé de mêler les deux projets alors que ce sont deux opérations indépendantes, toutes deux très larges et toutes deux risquées, et qui n'auraient jamais du être tentées en même temps). Car si on a eu le temps de planifier le changement de licence, rien n'a permis aux contributeurs de s'attendre à un arrêt de 4 jours (et encore, vu les moyens choisis et les risques pris, je ne suis même pas certain que dans 4 jours, le nouveau serveur sera réellement opérationnel, et réellement testé avant de commencer à faire exécuter doucement puis plus
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 01/04/2012 18:46, Philippe Verdy a écrit : [...] Je reprends ce que disait PierreV : OSM, ça repose sur une fondation et du bénévolat. Il y a de la place pour toutes le bonnes volontés. Par contre les yaka et faut-qu'on sont déplacés. Surtout sur cette liste. Je n'ai aucun moyen de reprendre et de faire quoi que ce soit de ces tellement bonnes idées qui auraient fait que tout baignerait si on avait fait comme ça, comme, je crois bien, chacun sur la liste. Si des choses ne vont pas, autant le dire à ceux qui les mettent en œuvre. Et autant leur proposer un coup de main. Mais les plaintes continuelles ou suggestions sans effets sont saoulantes. Ça n'est pas parce qu'on a du soleil en abondance ces jours-ci qu'il faut gâter le climat ! Comme disait ma grand-mère : Tu ferais bien de tourner sept fois ta langue dans ton clavier avant de poster (je crois qu'elle ne disait pas tout à fait comme ça...) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
est ce que tu pourrait raisonner dans l'autre sens en étant positif? Sa se trouve ils ont prévu 4jours d'arret... mais 3jours de travail suffi amplement si ils ne rencontrent pas de problème... et pourraient éventuellement rendre le service d'écriture dispo plus tot que les 4jours Faut pas oublier que le service lecture de la base de donnnée est actif lui... et a uniquement eu un arret pendant la nuit... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610644.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 01/04/2012 20:13, PierreV a écrit : est ce que tu pourrait raisonner dans l'autre sens en étant positif? Sa se trouve ils ont prévu 4jours d'arret... mais 3jours de travail suffi amplement si ils ne rencontrent pas de problème... et pourraient éventuellement rendre le service d'écriture dispo plus tot que les 4jours Faut pas oublier que le service lecture de la base de donnnée est actif lui... et a uniquement eu un arret pendant la nuit... ;-) @PierreV Je crois bien qu'il écoute mais je doute qu'il entende... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 20:21, Vincent Pottier vpott...@gmail.com a écrit : @PierreV Je crois bien qu'il écoute mais je doute qu'il entende... Tu supposes... j'entends bien. C'est un avis que je tente de justifier. Vous pouvez penser que c'est « négatif », mon propos n'est pas là. J'ai déjà fait dans le passé (il y a plus de 10 ans déjà) des migrations de type Big Bang. C'est fini. Sur ce type de projet volumineux, on ne prends plus jamais un tel risque. On conçoit les projets pour que les migrations se fassent en petites étables gérables et prévisibles. Car on se rend compte toujours à la fin de telles migrations que c'était un gaspillage de ressources et que ça a coûté bien plus cher que prévu (non seulement pour la migration elle-même mais aussi pour les autres services ou personnes qui en dépendent). La Fondation a sous-estimé les coûts et va vite s'en rendre compte, et regretter sa décision. Si au moins cela influence son travail futur pour ne plus jamais prendre de telles décisions unilatérales, on y gagnera quelque chose et le projet sera viable. Sinon il perdra de sa notoriété, et ce sont d'autres projets qui en profiteront (y compris des projets commerciaux comme ceux de Google et Apple) pour prendre la place d'OSM. Maintenant il va falloir batailler ferme pour qu'OSM conserve sa place chèrement gagnée, et ne perde pas une partie significative de contributeurs qui trouveront mieux leur place sur d'autres projets (oui FOSM pourrait grandir et parvenir à dépasser OSM, on verra bien dans quelques mois si les sources qui jusqu'à présent faisaient confiance à OSM ne choisiront pas finalement une licence Creative Commons, en rejetant ODDbl, pour finalement fournir leurs données librement à FOSM). On a maintenant un vrai risque qu'OSM ne soit plus un projet de couverture mondiale (comme Google) mais un projet défendu seulement dans certains pays (comme aussi FOSM qui continuera dans d'autres pays). Puis finalement que cette division aboutisse à faire gagner à nouveau les projets commerciaux (Google se frotte déjà les mains !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Dans JOSM on n'a pas encore moyen de consolider sur deux bases ses modifs. Cela supposerait gérer la source des modifications. Cela ne serait possible que pour les créations de *nouveaux* objets, qu'il faudrait ensuite recoller séparément dans chaque base (puisque cela entrainera automatiquement des objets en doublon on non connectés). Bref trois travaux à faire et non seulement deux, et certainement pas un seul travail avec les outils d'édition actuels, qui ne savent pas encore gérer les conflits d'édition dans des couches distinctes selon les serveurs consultés ou à mettre à jour (notamment JOSM dont le système de gestion des conflits est encore très mauvais et crée une simple liste au lieu de créer une couche permettant de visualiser et comparer correctement les modifs apportées). Le 1 avril 2012 13:29, PhQ pierre.que...@sfr.fr a écrit : Bonjour, Donc, OSM change de licence, et FOSM évidement pas. Jusqu’à maintenant, toute contribution à OSM se répercutait dans FOSM comme dans n'importe quelle site miroir. Mais, OSM et FOSM sont désormais distincts à partir du 1er avril 2012. (fork d'où le titre) La nouvelle licence Odbl autorise t'elle FOSM à répercuter les contributions OSM (à supposer que cela soit dans leurs intentions) ? L'inverse est de toute évidence non puisque OSM élimine toutes les contributions CC by SA strict. J'arrive donc a la question qui fâche : Si je veux que mes contributions profitent aux deux projets, est il pertinent d'uploader les mêmes objets sur les deux projets ? Y a t'il (Y aura t'il) un moyen d'éviter cette contrainte ? Bon Appétit. -- View this message in context: http://gis.19327.n5.nabble.com/4-jours-pour-digerer-le-coup-de-fourchette-tp5610210p5610210.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Pendant ces 4 jours d'arrêt, que faire d'autres que ces longues discussions qui ne vont nulle part ? Peut-être prendre du recul et voir où les efforts seraient les plus utiles. Et justement, si votre plume (ou clavier) est en mal d'écriture, pourquoi ne pas essayer entre autres d'éditer le wiki ? Il est un peu poussiéreux! Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Le 1 avril 2012 20:41, Philippe Verdy verd...@wanadoo.fr a écrit : notamment JOSM dont le système de gestion des conflits est encore très mauvais Si tu as des patchs à proposer on prend avec plaisir hein. Il y a encore beaucoup de problèmes avec le système de gestion des conflits, je ne le nie pas, mais de là à le qualifier de très mauvais... Par contre, pour la gestion multi-bases des informations, c'est en partie possible avec le tout récent plugin SDS de Frederik Ramm: http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html où l'idée est de séparer les tags selon leur provenance: la base OSM ou un serveur SDS (utilisé pour HOT). Il est peut-être possible que les mécanismes qui ont été intégrés dans le noyau JOSM pour ce plugin soient réutilisables pour de la duplication d'envoi vers FOSM, si quelqu'un d'aventureux était prêt à réaliser un plugin pareil (j'avertis de suite, ça ne m'intéresse pas). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 20:56, Pierre Béland infosbelas-...@yahoo.fr a écrit : Pendant ces 4 jours d'arrêt, que faire d'autres que ces longues discussions qui ne vont nulle part ? Peut-être prendre du recul et voir où les efforts seraient les plus utiles. Et justement, si votre plume (ou clavier) est en mal d'écriture, pourquoi ne pas essayer entre autres d'éditer le wiki ? Il est un peu poussiéreux! +1 ! ces discussion interminables sur l'administration des serveurs OSM n'ont rien à faire sur talk-fr. Sauf si un sysadmin français est présent sur la liste, mais je ne crois pas. En plus du wiki OSM, comme le suggère Pierre, il y a aussi du boulot sur la partie française du wiki de JOSM, ou la traduction de JOSM sur Launchpad, pour ne citer que 2 exemples. Puis on peut aussi faire un break, c'est seulement 4 jours d'arrêt ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
J'ai aussi d'autres choses à faire, rassure-toi. En revanche le wiki ne me motive pas pour le moment. Il y a d'autres projets qu'OSM (et pas liés à la cartographie). Ces disussion doivent mener à quelquechose car le service va redémarrer, masi dans des conditions différentes. Il y aura des choses à vérifier, à commencer par une comparaison des dumps de la base avant et après le changement de serveur. Puis ensuite pour suveiller le travail du robot qui va commencer à nettoyer les données sous licence CC-BY-SA uniquement (alors que ces données proviennent d'autres données en doublon qui ont été effacées avant ou qui provenaient en fait d'autres sources que les utilisateurs qui n'ont pas accepté la licence, ces sources étant par ailleurs parfaitement compatibles avec la nouvelle licence). Je vois par exempel des points qui sont marqués à supprimer, lors qu'ils sont parfaitement identiques à des points qui étaient dans la base avant importés d'utilisateurs qui ont accepté la licence. Cela s'est produit par exemple dans le cadre de la résolution de conflits d'édition ou d'un travail de dédoublonnage, dont ce n'est pas toujours l'objet le plus ancien qui a été gardé par celui qui a supprimé l'ancien point tout en rejetant ou n'approuvant pas la nouvelle licence, ou parce qu'arbitrairement la mauvaise version a été gardée par un autre utilisateur à un moment où il n'était même pas question encore de changer de licence. Si on regarde dans le détail, une quantité improtant d'objets ont leur géométrie qui vient directement de sources publiques libres. Les données réellement provenant des utilisateurs sont celles de travaux de vectorisation sur l'ancienne imagerie Yahoo, ou bien des ajouts de petits POIs (des commerces notamment, ou des tags de commentaires). Une grande quantité des données de la base ne vient pas des utilsiateurs qui les ont inséré sans mentionner la source réelle. Dans d'autres cas, des points ont été ajoutés pour corriger les géométries en relation avec d'autres objets voisins existants, qui au départ étaient compatibles avec la nouvelle licence. Les fusions de chemins, de noeuds, de relations en doublon, etc... ont commencé bien avant. Une vérification stricte basée uniquement sur l'historique d'un objet sans tenir compte de ses voisins en doublon (qui depuis ont été supprimés) risque de casser beaucoup de choses (il faudrait pouvoir annuler une ancienne suppression d'un objet compatible, mais ces données ne sont pas téléchargées par défaut dans les outils d'édition, ce qui complique énormément le travail de récupération des historiques...). En plus je ne suis même pas certain que la nouvelle base contiendra tous les historiques d'anciens objets supprimés. Car le processus de migration n'a de serveur pas été documenté (et dans l'urgence des 4 jours, ces données marquées comme supprimées risquent tout bonnement d'être sacrifiées, en plus du fait qu'elles ne sont déjà plus dans les dumps téléchargeables...) Il y a eu des centaines millions d'heures de travail sur cette base. En sadrifier même ne serait-ce que 1% signifiera des millionsd'heures pour rien, soit le travail de dizaines de milliers de petits contributeurs. Autant qui sont perdus pour le projet OSM et qui iront sur d'autres sans avoir l'impression que leut petite contribution, même modeste, servira à quelque chose ou à quelqu'un pendant une durée suffisante Le projet OSM n'est pourtant pas si vieux que ça, bon nombre de ces données sont encore parfaitement valides, même si on n'a pas pu contacter tout le monde ou parce qu'ils sont devenus injoignables par leur ancienne adresse, ou parce qu'ils ne peuvent de toute façon pas répondre car ils sont tout bonnement décédés sans possibiltié pour leurs successeurs d'accéder à l'ancien compte de messagerie, ou en traitement lourd dans un hôpital sans accès à leur messagerie, ou parce qu'ils n'ont plus les moyens d'avoir un accès Internet : c'est un bel hommage qu'on leur fait que d'oublier leur travail passé, tout bonnement parce qu'ils n'ont pas répondu ; hors le projet OSM est normalement destiné à être un ***développement durable***, pas un truc jetable à tout moment et après seulement une poignée d'années d'existence réellement publique. Aussi je comprend tout à fait le démarrage de FOSM, qui pour moi n'est **pas** dut tout un fork (le fork réel, c'est OSM qui l'a fait tout seul, même s'il a prévenu ses contributeurs qu'il allait le faire en sacrifiant des données anciennes, ce qui n'était pas du tout nécessaire, et reste une erreur grave : on n'a approuvé publiquement le changement de licence que pour les nouvelles contributions, mais on n'a jamais approuvé la suppression des anciennes données qui auraient du garder leur licence et rester disponibles, et meˆme encore modifiables selon les termes de l'ancienne licence et des sources réelles mentionnées ou non). Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Si t'est si mécontent de la gestion d'OSM... pourquoi tu ne monte pas ton propre projet libre verdy-géo? où tu appliquerais tout les *nombreux* conseils que tu donnes sur cette liste? @Pierre c'est ce que j'ai commencé dès hier soir en mettant à jour mon profil d'user... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610858.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
J'applique aussi la méthode TL;DR donc mes excuses si les phrases suivantes sont sorties de leur contexte : C'est en plus un gaspillage de ressources qui va coûter bien plus cher que prévu Je ne vois aucun coût à part le temps libre que mettent à disposition les contributeurs dans ce projet. Il a déjà eu pour effet de diviser la communauté qui soutenait le projet L'arrêt de 4 jours n'y est pour rien, c'est le manque de communication de la Fondation (c'est une habitude il parait). Et mis en exergue une prise de pouvoir inconsidérée par la Fondation et ses quelques administrateurs « autorisés » désignés par elle qui vont dans ces 4 jours prendre des décisions sacrificielles dans l'urgence Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. De même il était parfaitement possible de gérer dans la base de données des conditions de licence différentes C'est exactement ce qui est en cours, d'où l'introduction d'un nouveau champ redaction dans la base. car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Par contre tu as raison pour l'aspect Big Bang, c'est bien pour ça que le 1er plan avec un arrêt du 27 Mars au 1er Avril pour tout faire a été rejeté par la rebuild team et qu'OSM est passé sur un bot en tache de fond pour le basculement des données en ODbL. Francisco, qui a tenté (sans succès) de faire court. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Pour moi, l'idée serait que tout ce qui est téléchargé depuis une base donnée l'est uniquement dans son propre calque (mentionnant sa source), ce calqué étant toujours en lecture seule, alors que tout ce qu'on crée ou modifie cas dans un calque séparé. Les calques sont alors comparables. En cas de conflits d'édition, les données venant de la base sont mises à jour dans le calque en lecture seule, rien n'est mis dans notre calque. De même on doit pouvoir séparer la sauvegarde locale de ces calques: les données en lecture seule vont dans un fichier cache, mais rien n'y est sauvé concernant nos données créées modifiiées. Un autre fichier est utilisé pour nos données créées ou modifiées, ce ficier contenant une référence éventuelle (pas nécessaire) au fichier de cache. Si on charge notre fichier en cours de modification, il peut toujours régénérer à tout moment le fichier de cache du calque en lecture seule. Ainsi, on pourrait travailler avec plusieurs bases simultanément: chaque base ayant son calque en lecture seule. Puisque ce sont des calques séparés, les comparaisons sont possibles. Et si les bases mentionnent des licences permettant un import compatible, on peut transférer dans l'éditeur automatiquement les données d'un calque vers notre calque de modification (qui contient la référence du calque d'origtine de chaque objet). Mais pour faire ça, il faut que la référence d'un objet (son identifiant unique) soit distingué calque par calque: les identifiants uniques utilisés dans une base ne sont pas les mêmes que les idnetifiants uniques dans une autre, meˆme si c'est le même objet. De même les identifiants uniques locaux créés par nos objets crées ou modifiés, n'ont rien à voir avec les identifiants des calques d'origine. Pour gérer cela, il sufffirait que notre cache local de modification contienne pour chaque objet un tag spécial mentionnant une liste d'identifiants, un pour chaque base d'origine). Gérer les conflits se fait alors sur la carte directement, en comparant les calques. Et non plus dans une liste d'objets très difficile à interpréter (cette liste ne permet pas réellement de comparer les géométries, uniquement les valeurs d'attributs; les références des membres de relation sont trop difficiles aussi à vériifier). Pire: dans JOSM il est impsosible de sauvegarder des modifs en cours tant qu'il y a des conflits. Si on ne fait et qu'on recharge le fichier, on aboutit à des incohérences graves (plus des tonnes de bogues tels que des pointeurs nuls, ou références introuvables, ou des chemins sans noeuds, relations sans membres) et encore plus de conflits ensuite lors d'une tentative de sauvegarde. Le problème vient en fait du format des fichiers OSM. Il y manque pour chaque objet (noeud, relation, chemin) un sous-élément contenant une liste des identifiants externes, indiquant l'origine réelle d'un objet qui aurait été modifié ou importé aussi dans une autre base, sous forme d'une courte URN (par exemple en XML, cela peut être un court préfixe de namespace attribué symboliquement, suivi d'un :, suivi de la valeur de l'identifiant externe, le namespace étant défini par un autre objet dans l'entête du fichier OSM pour l'associer à l'URL de la source avec éventuellement aussi des notes personnelles librement modifiables tels qu'une liste de tâches à faire avec cette source). Pour l'instant on mentionne les identifiants externes (par exemple les CLC_ID de la base Corine, ou les autres identifiants venant de divers bases GIS, au format OSM ou non) en tant qu'attributs, mais à mon avis c'est une erreur et ça pollue en fait les attributs, et il n'y a pas de garantie de conserver les sources comme l'impose les licences: ces identifiants externes ne sont PAS librement modifiables et ne devraient être supprimables non plus dans JOSM. En utilisant des calques séparés poru chauqe source (qu'on peut visualiser ensemble par transparence ou alternativement), plus besoin de la liste des conflits: c'est un calque calculé automatiquement (lui aussi non modifiable) qui permet d'afficher un fitlre de comparaison pour recolorer certains objets en rouge ou d'entourer les noeuds en jaune. Dès qu'on touche au calque de travail sur un objet en conflit, le calque de conflits se remet à jour tout seul (il faut un calque de conflit par base d'origne, donc si on veut synchroniser avec deux bases différentes, cela ferait 5 calques en tout (les 2 calques de cache en lecture seule, notre calque de travail, et les deux calques calculés automatiquement des conflits entre notre claque et les bases qu'on voulait synchroniser). Pour cimplifier l'interface, au lieu d'avoir 5 calques listés, on pourrait n'en lister que 3 (mais les deux calques des caches en lecture seule aurait un petit menu déroulant contextuel avec des cases à cocher, indiquant les comparaisons à faire entre ce calque et un des autres calques, pour que soit marqué en rouge ou entouré ceux des objets du calque courant à mettre en avant, ou pour masquer ou
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : J'applique aussi la méthode TL;DR donc mes excuses si les phrases suivantes sont sorties de leur contexte : C'est en plus un gaspillage de ressources qui va coûter bien plus cher que prévu Je ne vois aucun coût à part le temps libre que mettent à disposition les contributeurs dans ce projet. Tu crois que la Fondation n'utilise pas des moyens financiers (matériels, services, personnels) pour faire cette migration ? Cette migration a bel et bien un coût réel, financé par les donations qu'elle reçoit, et qu'elle doit aussi gérer avec économie et de façon intelligente. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Ce que tu proposes est très éloigné d'une simple réécriture du système de gestion des conflits, c'est une énorme refonte de pans entiers de JOSM sur sa gestion des données en général. C'est pratiquement la création d'un nouvel éditeur ! Je ne sais pas si tu réalises la quantité de travail nécessaire pour réaliser un truc pareil, mais ça me semble bien au delà de nos ressources actuelles. Il est en tout cas peu probable qu'on s'investisse dans un projet tellement pharaonique s'il n'y a pas un réel besoin et une demande forte pour ça. Et non, ce genre de discussions qui s'annoncent très longues et très techniques n'ont pas non plus leur place ici. La liste josm-dev est là pour ça, merci de l'utiliser :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur. Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. C'est un apriori. Non décrit dans le plan de migration en court. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. Etant donné le plan d'urgence des 4 jours donnés pour faire le travail, ils n'auront guère d'autre choix que de sacrifier une partie des données en cas de problèmes, sinon ils ne redémarrent pas ! car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur, en tout cas pas pour ce type de projet collaboratif. D'une façon ou d'une autre, s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.) permettant de tracer toutes ses actions. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Non. Le rique est réel. Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des migrtions de bases de données dans le passé, on a toujours rencontré des problèmes de compatibilité sur des bases de données très volumineuses. Pour passer le problème, on sacrifie une partie des données non convertibles (ou mal converties et rejetées dans le nouveaux schéma). Après reste à résoudre le problème de ces données manquantes (à condition de les avoir identifiées, conservées à part, afin de trouver une solution ultérieure pour elles, et analyser proprement pourquoi elles n'ont pas été acceptées et ce qu'on peut faire pour les corriger. Sur des données aussi volumineuses, ces données en conflit peuvent elles aussi être très volumineuses et demander plus que 4 jours pour les convertir proprement, au moins en partie, tout en sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin de pouvoir vérifier aussi l'intégrité des données qui sont passées. Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Et il n'est pas inintéressant de lire les notes de compatibilité entre PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne seulement une idée sommaire (le détail est plus compliqué si on tient compte de la plateforme matérielle ou OS) : http://www.postgresql.org/docs/9.1/static/release-9-1-3.html Ainsi que les notes de bogues existants pour ces migrations. Car il y en a ! http://www.postgresql.org/docs/9.1/static/release-9-1.html Certains outils ont des bogues jugés « non critiques » comme des fuites mémoire, qui pourtant commenceront à tout planter au milieu passé un certain volume de données traitées. D'autres choses concerne la stabilité des tris et index. La compatibilité des critères d'unicité pour les collations (changement de version des bases CLDR ou Unicode par exemple). Aussi, la compatibilité des systèmes I/O (en cas de changement de version de l'OS hôte ou de son architecture matérielle). Des contraintes liées aux processeurs pour la synchronisation multithread (certaines procédures SQL qui n'avaient à priori pas besoin de synchronisation vont en avoir besoin, ou bien il y a de nouveaux deadlocks entre sections critiques, générant des erreurs SQL et des rollbacks implicites de transactions qui passaient sans problèmes avant). Des différences aussi dans la syntaxe SQL ou le support des plugins GIS, ou dans la version du noyau de VM si le moteur supporte les traitements dans une VM intégrée au moteur, tel que Java, ou des différences de comportement et de compatibilité avec d'autres plugins en code natif (certains intégrant des mots-clés, fonctions, types SQL supplémentaires, ou de nouvelles méthodes d'indexation et de recherche et jointure), ou de nouvelles restrictions de sécurité. Espérons que le logiciel a déjà été testé sur le nouveau serveur, avec
[OSM-talk-fr] Re : OSM en read-only (était : Vélib' Paris)
Comme tu n es pas en contact avec les admins de la base OSM et que tu juges leurs decisions/actions sans savoir ce qu ils font voici leurs adresses mails : Tom Hughes t...@compton.nu; et openstreet...@firefishy.com openstreet...@firefishy.com; Tu as plein de choses interessantes a leur expliquer et a leur apprendre, pense a garder au moins la liste osm-fr-dev en copie afin que nous puissions apprecier pleinements tes contributions Julien De : Philippe Verdy verd...@wanadoo.fr À : f.dos.san...@free.fr Cc : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Dimanche 1 avril 2012 23h24 Objet : Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris) Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur. Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. C'est un apriori. Non décrit dans le plan de migration en court. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. Etant donné le plan d'urgence des 4 jours donnés pour faire le travail, ils n'auront guère d'autre choix que de sacrifier une partie des données en cas de problèmes, sinon ils ne redémarrent pas ! car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur, en tout cas pas pour ce type de projet collaboratif. D'une façon ou d'une autre, s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.) permettant de tracer toutes ses actions. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Non. Le rique est réel. Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des migrtions de bases de données dans le passé, on a toujours rencontré des problèmes de compatibilité sur des bases de données très volumineuses. Pour passer le problème, on sacrifie une partie des données non convertibles (ou mal converties et rejetées dans le nouveaux schéma). Après reste à résoudre le problème de ces données manquantes (à condition de les avoir identifiées, conservées à part, afin de trouver une solution ultérieure pour elles, et analyser proprement pourquoi elles n'ont pas été acceptées et ce qu'on peut faire pour les corriger. Sur des données aussi volumineuses, ces données en conflit peuvent elles aussi être très volumineuses et demander plus que 4 jours pour les convertir proprement, au moins en partie, tout en sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin de pouvoir vérifier aussi l'intégrité des données qui sont passées. Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Et il n'est pas inintéressant de lire les notes de compatibilité entre PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne seulement une idée sommaire (le détail est plus compliqué si on tient compte de la plateforme matérielle ou OS) : http://www.postgresql.org/docs/9.1/static/release-9-1-3.html Ainsi que les notes de bogues existants pour ces migrations. Car il y en a ! http://www.postgresql.org/docs/9.1/static/release-9-1.html Certains outils ont des bogues jugés « non critiques » comme des fuites mémoire, qui pourtant commenceront à tout planter au milieu passé un certain volume de données traitées. D'autres choses concerne la stabilité des tris et index. La compatibilité des critères d'unicité pour les collations (changement de version des bases CLDR ou Unicode par exemple). Aussi, la compatibilité des systèmes I/O (en cas de changement de version de l'OS hôte ou de son architecture matérielle). Des contraintes liées aux processeurs pour la synchronisation multithread (certaines procédures SQL qui n'avaient à priori pas besoin de synchronisation
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Et 2 minutes pour apprendre à être insultant. Le 1 avril 2012 23:47, sly (sylvain letuffe) li...@letuffe.org a écrit : Le dimanche 1 avril 2012 23:43:05, Vincent Pottier a écrit : Si ta parole n'est pas plus belle que le silence, garde le silence proverbe arabe, mais, semble-t-il issu des apophtegmes des Pères. J'en rajoute une très à propos : Il faut 4 ans pour apprendre à parler, et toute une vie pour apprendre à se taire -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
tu l'as un peu beaucoup cherché... déjà si tu commençais à être beaucoup plus concis lors de tes réponses on aurait peut être une réaction autre. Mais tu persistes à faire tes grands discours... et pour continuer sur les citations: Les grands diseurs ne sont pas les grands faiseurs. Léon Martel sur ce bonne nuit -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5611130.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Le 02/04/2012 00:07, Philippe Verdy a écrit : Et 2 minutes pour apprendre à être insultant. Ça, non ! Moqueur, peut-être un peu quoique les choses fussent dites élégamment. Vexant, peut-être. Mais qui se sent morveux, qu'il se mouche ! Insultant, non. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Continue comme ça le ton insultant avec les termes comme grand discours. Je ne cherche à insulter personne, c'est mon style, et pas destiné et parler plus fort qu'un autre. Qu'un message soit court ou long revet le même importance, chacun trouve les mots selon ce qu'il veut dire et selon l'impression qu'il a de bien transmettre ce qu'il veut dire. En revanche le ton compte pour beaucoup plus pour moi, et le tien est fortement désagréable et en plus en fait une question personnel, ce qui contraire à l'étiquette. Si ce style ne te plait pas, mais c'est pas une raison pour réagir de cette façon. Et tu n'es pas obligé de tout lire. Le 2 avril 2012 00:34, PierreV belett...@hotmail.fr a écrit : tu l'as un peu beaucoup cherché... déjà si tu commençais à être beaucoup plus concis lors de tes réponses on aurait peut être une réaction autre. Mais tu persistes à faire tes grands discours... et pour continuer sur les citations: Les grands diseurs ne sont pas les grands faiseurs. Léon Martel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] ref_NUTS ou ref:NUTS ?
Bonsoir, Selon la page wiki FR:Key:ref, c'est la clef ref:NUTS qui doit être utilisée pour les entités administratives. Selon taginfo, c'est ref_NUTS qui est utilisé. Pour une cohérence avec ref:INSEE, je pencherai pour ref:NUTS On a quelques jours pour débattre avant de pouvoir faire des changements. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref_NUTS ou ref:NUTS ?
Shame on me ;) Tu peux regarder, ces ref_NUTS c'est moi qui les ai créé, à ma connaissance il n'y en a pas eu d'autres d'ajouté. Aucun problème pour moi pour les passer en ref:NUTS, c'est effectivement bien plus logique ! Le 2 avril 2012 01:08, Vincent Pottier vpott...@gmail.com a écrit : Bonsoir, Selon la page wiki FR:Key:ref, c'est la clef ref:NUTS qui doit être utilisée pour les entités administratives. Selon taginfo, c'est ref_NUTS qui est utilisé. Pour une cohérence avec ref:INSEE, je pencherai pour ref:NUTS On a quelques jours pour débattre avant de pouvoir faire des changements. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Erreur IPv6 sur openstreetmap.org
Bonjour, Ce n'est certainement pas le lieu le plus adapté pour reporter le problème, donc si quelqu'un a une adresse plus adaptée je suis preneur. J'ai une erreur quand je tente d'accéder les tuiles osm en passant pas le serveur proxy de mon FAI. Le FAI me dit que son système n'est pas en cause, mais que l'accès en IPv6 aux tuiles ne serait pas possible, d'où l'erreur. Ci dessous l'échange que j'ai eu: ,- [ ] | Le Lun 02 Avr 2012 11:11:56, \\\@/.nc a écrit : | Bonjour, si je tente d'acceder les tuiles de chez | openstreetmap.org en | | passant par le proxy, j'obtiens le message suivant: | | Bonjour, | | L'erreur suivante a été rencontrée en essayant d'accéder à l'URL : | http://a.tile.openstreetmap.org/16/63071/36927.png | | La connexion à 2a02:80:0:3ff8:222:64ff:fe2a:2714 a échouée. | | Le système a retourné : (101) Network is unreachable | | The remote host or network may be down. Please try the request | again. | | | Votre administrateur de cache est cont...@nautile.nc. | | En effet, l'accès IPv6 au serveur web de a.tile.openstreetmap.org est | indisponible, alors que sa connectivité IPv6 fonctionne bien. L'accès | IPv4 fonctionne sans soucis en revanche. | | Un proxy n'est malheureusement pas capable de retomber en IPv4 après | un échec de connexion en IPv6. | | Il serait donc plutôt souhaitable de contacter les administrateurs | système d'OpenStreetMap afin de leur rapporter cette erreur. | | Cordialement, | | L'accès direct marche très bien. | | Cordialement | Hendrik | | | | -- | Nicolas Aupetit - Nautile `- -- Cordialement Hendrik Oesterlin Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] [FYI]Yahoo!ロコにOSMレイヤーが追加されました
としです。 既にご存じの方も多いかと思いますが Yahoo!ロコにOSMレイヤーが追加されました。 http://maps.loco.yahoo.co.jp/maps 落ち着いた美しいデザインで、非常にすっきりしています。 結構見やすいですね。これはありだと思っています。 最近は仕事が激多忙すぎるのですが、またマッピングしていきまっすー ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 福山でOpenStreetMapの地図を作ってみる集まり
こんにちは。野方です。 STLUG(瀬戸内Linuxユーザー会)のMLで、広島県福山市でのマッピングパーティ告知が流れていました。 4月21日13時から開催だそうです。 福山でOpenStreetMapの地図を作ってみる集まり : ATND: http://atnd.org/events/27318 -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [FYI]Yahoo!ロコにOSMレイヤーが追加されました
On Sun, Apr 01, 2012 at 05:23:28PM +0900, TANAKA Toshihisa wrote: 落ち着いた美しいデザインで、非常にすっきりしています。 結構見やすいですね。これはありだと思っています。 もっとデザインに凝ると、 http://maps.google.co.jp/maps?t=8utm_campaign=8bitutm_source=jpblog かな(笑)。 これはやられた、と思いました。 oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 2012年03月20日 釜石復興マッピングパーティのお知らせ
On Fri, Mar 23, 2012 at 08:45:04PM +0900, ribbon wrote: OSCの会場で、Joe's Webホスティングの方が、コミュニティの方向けに、 会議室を貸してくれる、アナウンスをしていました。東京だと 銀座一丁目にあるそうです。平日の昼、一部夜だけで、休日は無理ですが。 KDDIのcloudcoreでも開発者支援制度があるようです。 http://www.cloudcore.jp/vps/develop/ oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 福山でOpenStreetMapの地図を作ってみる集まり
野方さん、ご紹介ありがとうございます。 OSM.jpにも掲載させて頂きました。 http://openstreetmap.jp/node/93 なお、OSMに関わるイベントはOSM.jpにユーザ登録している方なら どなたでも投稿して頂けます。 宜しければご利用ください。 OSM.jpにログインして左サイドで コンテンツ作成＞ミーティング を選びます。 東 12/04/01 Jun NOGATA noga...@gmail.com: こんにちは。野方です。 STLUG(瀬戸内Linuxユーザー会)のMLで、広島県福山市でのマッピングパーティ告知が流れていました。 4月21日13時から開催だそうです。 福山でOpenStreetMapの地図を作ってみる集まり : ATND: http://atnd.org/events/27318 -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 東日本大震災の避難所データについて
いいだです。 ライセンス非承認の避難所Node あ、これからのデータの消え方、誤解していました。 4月の最初のダウンタイムのときに、非承認データに対して「APIからミエナクナール」フラグを立ててロックしておいて、 そこから徐々にデータを消してゆく作業方針ぽいですね。 # APIから見えなくなるだけで、非承認データは残り続けるものだと思っていました。 http://wiki.openstreetmap.org/wiki/OSMFJ/License/Rebuild_Plan それであれば、もう既にメンテにも入ってしまっていますし、 一度消えちゃうのはしょうが無いですね。 4Dデータエディタ はい、エディタが対応すると、このへんはとても進みが早そうです。 面白い試みだと思うので、うまく進むと良いなぁ。 2012年3月29日21:39 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 ■1. ライセンス非承認の避難所Node ライセンス的に正しいデータをどうやって残すか、悩んでいます。 もう一度同じデータをインポートしてから残すための処理をするしかない？ ここは悩むとキリが無さそうなので 消えてしまうものは仕方がないと考えてはいかがでしょうか。 ■2. 残り続けるデータの扱い 今回のデータに限らず、4Dマッピングのためにデータを残し続けるということは、 それら残る地物の大きさや数によっては これからの編集作業の邪魔になるかもしれないと感じています。 どのような形で残して / 消してゆくか、 こちらについてもご意見いただけると嬉しいです。 # この話題はもしかしたら、英語の本家MLで行われているのかな？ なるほど。詳細に考え出すと奥深いですね。 カレントで無い(例えばend_dateの入った)オブジェクトは エディタに表示させないようなオプションが必要でしょうね。 4D用のエディタやレンダラーは検討されているようです。 http://wiki.openstreetmap.org/wiki/OSM-4D#4D_editor 将来の登場を期待したいです。 タグの付け方は、ドイツ語のページを見ると http://wiki.openstreetmap.org/wiki/DE:OSM-4D#Tagging_2 お店や道路の変遷をリレーションで表現しています。 でも時間経過とともにあらゆるオブジェクトが全てリレーションになるというのは 編集がちょっとつらそうですね。 2012年3月26日0:57 yuu hayashi hayashi@gmail.com: ハヤシです。 東さんへ ＋１ です。 今回の釜石マッピングパーティの「復興していく〜を記録しよう！」という目的からも、時間情報が記録できるのであれば記録していくべきであると考えます。 被災＝＞避難所＝＞仮設＝＞復興 の流れを記録できるというほかにも、 例えば、大雨でがけ崩れが発生して道路が通行止めになったとした場合に、 「いつから通行止めになり、いつ復旧した（する）」という情報発信としての役割の他にも、 「どのぐらいの大雨が降ると、どれだけの地点がどのぐらいの期間影響を受ける」かといった予測データとしても使えるようになるかもしれません。 災害以外にも、オリンピックや万博会場のような変遷がみれると楽しいと思います。 身近なところでは、道路工事が、どの地点で、何時から何時までやる。という情報が地図上で確認できるといいとは思います。 以上、 OSMの将来性に期待しているいち個人の感想でした。 2012年3月25日22:57 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 この件、どうしたら良いか、あれこれ考えていたのですが 災害への対応という視点で考え始めるといろいろ検討すべきことがありそうなので それは別の機会にして 今回はOSMでの時系列データの扱いという視点で考えてみました。 避難所に限らず、閉鎖された店舗や宅地化された森林など 世の中の移ろいゆく姿は、googleなどで画像として表現している事例はありますが これまで地理データとしてはあまり表現されてこなかった 部分だと思います。 今回の震災でも明治初頭の迅速測図が、液状化を起こしやすい 場所の再発見につながったという話もありました。 そういう点で自由な地図であるOSMで、時間軸での変化をデータとして記録し 例えば時間軸スライダーで変遷を表現できるとすれば 素晴らしいことではないでしょうか。 現実から消えてしまったデータを削除するのもひとつの考え方だと思いますが 過去を振り返りたい場合が出てくる可能性もあります。 ということで、私としては時間軸の表現、4Dマッピングの中で この避難所のデータも扱うことを提案したいと思います。 長くなりましたが、4Dマッピングのページを見ると http://wiki.openstreetmap.org/wiki/OSM-4D start_dateやend_dateで時間軸を表現しようとしているようなので 使われなくなった避難所は、レンダリング対象外とすることも含め disused:tourism=camp_site end_date=使われなくなった日付(アバウトに年だけでも可) といったタグに付け替えるということでいかがでしょうか。 12/03/25 ribbon o...@ns.ribbon.or.jp: On Sat, Mar 24, 2012 at 09:02:50PM +0900, TANAKA Toshihisa wrote: 1. 次の大規模災害で使うかもしれないので、「disused=yes」のタグを付けてNodeを残しておく 2. いったん完全に削除してしまう 私の意見は、広域避難場所、指定避難所以外は削除です。 もし、次の何らかの広域災害があったとして、「前はここだったから。。。」と言うのは、 時系列的に見て正しい情報になっているか懸念が残るからです。 同上。 次回が同じ場所とは限りません。 oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 東日本大震災の避難所データについて
東です。 12/04/01 Satoshi IIDA nyamp...@gmail.com: いいだです。 ライセンス非承認の避難所Node あ、これからのデータの消え方、誤解していました。 4月の最初のダウンタイムのときに、非承認データに対して「APIからミエナクナール」フラグを立ててロックしておいて、 そこから徐々にデータを消してゆく作業方針ぽいですね。 # APIから見えなくなるだけで、非承認データは残り続けるものだと思っていました。 http://wiki.openstreetmap.org/wiki/OSMFJ/License/Rebuild_Plan 私も詳細はよく分かっていなかったのですが、APIの変更(予定)内容を見ると http://wiki.openstreetmap.org/wiki/Open_Database_License/Changes_in_the_API 承認者と否認者の編集が入り混じったオブジェクトについては おおよそ以下のようなことをやろうとしているようです。 ・改訂履歴(version)は物理的に残すが、 ライセンス否認者の編集したタグや位置情報はbotが一括してクリアし、 最終的に承認者が編集した内容だけを残した最新バージョンを自動生成する。 ・従来通りAPI経由でデータを取得しようとすると、 否認者の編集が及んでいるバージョンは取得できない。 ・ただし、botの更新内容を後で確認できるように、 APIをshow_redactions=trueモードで呼び出せば、 全バージョンを見ることができる。 それであれば、もう既にメンテにも入ってしまっていますし、 一度消えちゃうのはしょうが無いですね。 はい。ODbLとしてはもう復活できないと思います。 4Dデータエディタ はい、エディタが対応すると、このへんはとても進みが早そうです。 面白い試みだと思うので、うまく進むと良いなぁ。 2012年3月29日21:39 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 ■1. ライセンス非承認の避難所Node ライセンス的に正しいデータをどうやって残すか、悩んでいます。 もう一度同じデータをインポートしてから残すための処理をするしかない？ ここは悩むとキリが無さそうなので 消えてしまうものは仕方がないと考えてはいかがでしょうか。 ■2. 残り続けるデータの扱い 今回のデータに限らず、4Dマッピングのためにデータを残し続けるということは、 それら残る地物の大きさや数によっては これからの編集作業の邪魔になるかもしれないと感じています。 どのような形で残して / 消してゆくか、 こちらについてもご意見いただけると嬉しいです。 # この話題はもしかしたら、英語の本家MLで行われているのかな？ なるほど。詳細に考え出すと奥深いですね。 カレントで無い(例えばend_dateの入った)オブジェクトは エディタに表示させないようなオプションが必要でしょうね。 4D用のエディタやレンダラーは検討されているようです。 http://wiki.openstreetmap.org/wiki/OSM-4D#4D_editor 将来の登場を期待したいです。 タグの付け方は、ドイツ語のページを見ると http://wiki.openstreetmap.org/wiki/DE:OSM-4D#Tagging_2 お店や道路の変遷をリレーションで表現しています。 でも時間経過とともにあらゆるオブジェクトが全てリレーションになるというのは 編集がちょっとつらそうですね。 2012年3月26日0:57 yuu hayashi hayashi@gmail.com: ハヤシです。 東さんへ ＋１ です。 今回の釜石マッピングパーティの「復興していく〜を記録しよう！」という目的からも、時間情報が記録できるのであれば記録していくべきであると考えます。 被災＝＞避難所＝＞仮設＝＞復興 の流れを記録できるというほかにも、 例えば、大雨でがけ崩れが発生して道路が通行止めになったとした場合に、 「いつから通行止めになり、いつ復旧した（する）」という情報発信としての役割の他にも、 「どのぐらいの大雨が降ると、どれだけの地点がどのぐらいの期間影響を受ける」かといった予測データとしても使えるようになるかもしれません。 災害以外にも、オリンピックや万博会場のような変遷がみれると楽しいと思います。 身近なところでは、道路工事が、どの地点で、何時から何時までやる。という情報が地図上で確認できるといいとは思います。 以上、 OSMの将来性に期待しているいち個人の感想でした。 2012年3月25日22:57 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 この件、どうしたら良いか、あれこれ考えていたのですが 災害への対応という視点で考え始めるといろいろ検討すべきことがありそうなので それは別の機会にして 今回はOSMでの時系列データの扱いという視点で考えてみました。 避難所に限らず、閉鎖された店舗や宅地化された森林など 世の中の移ろいゆく姿は、googleなどで画像として表現している事例はありますが これまで地理データとしてはあまり表現されてこなかった 部分だと思います。 今回の震災でも明治初頭の迅速測図が、液状化を起こしやすい 場所の再発見につながったという話もありました。 そういう点で自由な地図であるOSMで、時間軸での変化をデータとして記録し 例えば時間軸スライダーで変遷を表現できるとすれば 素晴らしいことではないでしょうか。 現実から消えてしまったデータを削除するのもひとつの考え方だと思いますが 過去を振り返りたい場合が出てくる可能性もあります。 ということで、私としては時間軸の表現、4Dマッピングの中で この避難所のデータも扱うことを提案したいと思います。 長くなりましたが、4Dマッピングのページを見ると http://wiki.openstreetmap.org/wiki/OSM-4D start_dateやend_dateで時間軸を表現しようとしているようなので 使われなくなった避難所は、レンダリング対象外とすることも含め disused:tourism=camp_site end_date=使われなくなった日付(アバウトに年だけでも可) といったタグに付け替えるということでいかがでしょうか。 12/03/25 ribbon o...@ns.ribbon.or.jp: On Sat, Mar 24, 2012 at 09:02:50PM +0900, TANAKA Toshihisa wrote: 1. 次の大規模災害で使うかもしれないので、「disused=yes」のタグを付けてNodeを残しておく 2. いったん完全に削除してしまう 私の意見は、広域避難場所、指定避難所以外は削除です。 もし、次の何らかの広域災害があったとして、「前はここだったから。。。」と言うのは、 時系列的に見て正しい情報になっているか懸念が残るからです。 同上。 次回が同じ場所とは限りません。 oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
