Re: [talk-ph] Fwd: Invitation to an inter-agency meeting to discuss availability, quality and accessibility of common and fundamental operational datasets in the Philippines (June 16th, 2014)
Hello everybody, This is quite delayed, but I would like to provide a short report of what happened during the DSWD forum. I was able to attend the afternoon session (the morning session was reserved for government agencies). Basically, the idea of the forum is to provide a venue for government agencies and international humanitarian/aid organizations to talk about the problem of sharing (mostly geospatial) data sets related to disaster risk reduction, mitigation, response, and management. There has been a lot of activity surroung relied efforts for Typhoon Haiyan but these are usually uncoordinated leading to duplication of effort and missed opportunities. There were attendees from various government agencies: DBM, DSWD, DOH, DPWH, DOTC, PNP, CAAP, OCD, PAGASA, and NFA. There was a representative from DILG who attended the morning session; unfortunately the representative couldn't attend in the afternoon. Sadly, there was no representative from NAMRIA. Aside from the local OpenStreetMap community (represented by me and Julius), we also had attendees from the the international humanitarian/aid organizations: United Nations Office for the Coordination of Humanitarian Affairs (UN OCHA), World Bank (WB), Asian Development Bank (ADB), Japan International Cooperation Agency (JICA), and the International Organization for Migration (IOM). During the morning session, the following points were drawn up in order to address the main issue: 1. Data accessibility needs to be addressed, possibly through another workshop. This includes the use of open machine-readable formats (not just PDFs, or worse, scanned documents) and open licenses. 2. Availability and completeness of data, especially the fundamental data sets, needs to be tackled. One possible solution is to turn to crowd-sourcing to help complete missing data. Furthermore, it was pointed out that many data sets are maintained by the LGUs (example, administrative boundaries) so the cooperation of DILG is vital. 3. There is the issue of a lack of geospatial data specifications and standards. NAMRIA is the lead agency in charge of this item, and an inter-governmental workshop may be needed. 4. A policy for data sharing needs to be formulated. The NDRRMC is the body assigned for this item. 5. There is a need to promote and standardize the use of PSGC for referring to LGUs in all of the data sets. The afternoon session was basically a discussion of other points related to the ones listed above. I am not aware of any next steps yet, but I do hope this would lead to good things, and especially, a lot of open data sets. ~Eugene On Thu, Jun 12, 2014 at 11:08 AM, maning sambale emmanuel.samb...@gmail.com wrote: Dear Everyone, With permission from the organizers, OSM-PH community is invited to this event. They alloted 2-3 slots for OSM-PH. Program details and other documents here: https://drive.google.com/folderview?id=0B-2WZQ1DwK_xWHFHd1p6dGJQMG8usp=sharing -- Forwarded message -- From: Steeve Ebener steeve.ebe...@gaia-geosystems.org Date: Mon, Jun 9, 2014 at 9:28 AM Subject: Invitation to an inter-agency meeting to discuss availability, quality and accessibility of common and fundamental operational datasets in the Philippines (June 16th, 2014) Dear all, While waiting for the official invitation to reach you from DSWD, and apologizing in advance for such a short notice, I already wanted to share with you attached the agenda and paper for next week's meeting to discuss the availability, quality and accessibility of common and fundamental operational datasets to support disaster risk reduction and emergency management in the Philippines. This meeting, jointly organized by DSWD and the Strengthening Information Infrastructure for Emergency Management (SIIEM) project, will take place at the UP Asian Center. As per the attached agenda, the morning session will allow for Governmental institutions to comment on the attached paper and share their own data related experience and challenges faced during the response to typhoon Yolanda with the objectives to identify activities and resources that would be needed in order to unlock the main barriers to availability, quality and accessibility of these datasets. In the afternoon, the international community (donors, United Nations, Open Data Community,...) are invited to join the Governmental institutions to discuss how the activities and needs for resources identified during the morning could be covered. The morning session being limited to Governmental institutions, we would appreciate your confirmation of participation to the afternoon session by tomorrow COB. Please contact Mr. Lawrence Anthony S. Dimailig ( lasdimai...@dswd.gov.ph) or Ms. Vanity Joy B. Estremera ( vjbestrem...@dswd.gov.ph) at 931-8085 in this regards or for any other enquiries you might have. Looking forward to your Agency’s full support and active participation
Re: [talk-ph] Fwd: Invitation to an inter-agency meeting to discuss availability, quality and accessibility of common and fundamental operational datasets in the Philippines (June 16th, 2014)
Thanks for the update Eugene. Looking forward to what will happen next. On Mon, Jul 28, 2014 at 7:23 PM, Eugene Alvin Villar sea...@gmail.com wrote: Hello everybody, This is quite delayed, but I would like to provide a short report of what happened during the DSWD forum. I was able to attend the afternoon session (the morning session was reserved for government agencies). Basically, the idea of the forum is to provide a venue for government agencies and international humanitarian/aid organizations to talk about the problem of sharing (mostly geospatial) data sets related to disaster risk reduction, mitigation, response, and management. There has been a lot of activity surroung relied efforts for Typhoon Haiyan but these are usually uncoordinated leading to duplication of effort and missed opportunities. There were attendees from various government agencies: DBM, DSWD, DOH, DPWH, DOTC, PNP, CAAP, OCD, PAGASA, and NFA. There was a representative from DILG who attended the morning session; unfortunately the representative couldn't attend in the afternoon. Sadly, there was no representative from NAMRIA. Aside from the local OpenStreetMap community (represented by me and Julius), we also had attendees from the the international humanitarian/aid organizations: United Nations Office for the Coordination of Humanitarian Affairs (UN OCHA), World Bank (WB), Asian Development Bank (ADB), Japan International Cooperation Agency (JICA), and the International Organization for Migration (IOM). During the morning session, the following points were drawn up in order to address the main issue: 1. Data accessibility needs to be addressed, possibly through another workshop. This includes the use of open machine-readable formats (not just PDFs, or worse, scanned documents) and open licenses. 2. Availability and completeness of data, especially the fundamental data sets, needs to be tackled. One possible solution is to turn to crowd-sourcing to help complete missing data. Furthermore, it was pointed out that many data sets are maintained by the LGUs (example, administrative boundaries) so the cooperation of DILG is vital. 3. There is the issue of a lack of geospatial data specifications and standards. NAMRIA is the lead agency in charge of this item, and an inter-governmental workshop may be needed. 4. A policy for data sharing needs to be formulated. The NDRRMC is the body assigned for this item. 5. There is a need to promote and standardize the use of PSGC for referring to LGUs in all of the data sets. The afternoon session was basically a discussion of other points related to the ones listed above. I am not aware of any next steps yet, but I do hope this would lead to good things, and especially, a lot of open data sets. ~Eugene On Thu, Jun 12, 2014 at 11:08 AM, maning sambale emmanuel.samb...@gmail.com wrote: Dear Everyone, With permission from the organizers, OSM-PH community is invited to this event. They alloted 2-3 slots for OSM-PH. Program details and other documents here: https://drive.google.com/folderview?id=0B-2WZQ1DwK_xWHFHd1p6dGJQMG8usp=sharing -- Forwarded message -- From: Steeve Ebener steeve.ebe...@gaia-geosystems.org Date: Mon, Jun 9, 2014 at 9:28 AM Subject: Invitation to an inter-agency meeting to discuss availability, quality and accessibility of common and fundamental operational datasets in the Philippines (June 16th, 2014) Dear all, While waiting for the official invitation to reach you from DSWD, and apologizing in advance for such a short notice, I already wanted to share with you attached the agenda and paper for next week's meeting to discuss the availability, quality and accessibility of common and fundamental operational datasets to support disaster risk reduction and emergency management in the Philippines. This meeting, jointly organized by DSWD and the Strengthening Information Infrastructure for Emergency Management (SIIEM) project, will take place at the UP Asian Center. As per the attached agenda, the morning session will allow for Governmental institutions to comment on the attached paper and share their own data related experience and challenges faced during the response to typhoon Yolanda with the objectives to identify activities and resources that would be needed in order to unlock the main barriers to availability, quality and accessibility of these datasets. In the afternoon, the international community (donors, United Nations, Open Data Community,...) are invited to join the Governmental institutions to discuss how the activities and needs for resources identified during the morning could be covered. The morning session being limited to Governmental institutions, we would appreciate your confirmation of participation to the afternoon session by tomorrow COB. Please contact Mr. Lawrence Anthony S. Dimailig ( lasdimai...@dswd.gov.ph) or Ms.
Re: [talk-ph] Mozilla Maker Festival (Sep 13–14, 2014)
This is cool event. Let's braisnstorm what we want to do/showcase. On Sat, Jul 26, 2014 at 9:11 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi everyone, The Mozilla Philippines community is organizing a Maker Festival on September 13–14, 2014 (Saturday and Sunday) at the Glorietta 5 Atrium in Makati. More information: http://makerfestival.ph/ I think this is a really good event for OSM Philippines community to participate in. We could demonstrate all of the things that people have made using OSM data and maps, and that this is all possible because people contribute to the project. Is anybody free on those dates and would want to participate? :-) Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] talk-ph Digest, Vol 72, Issue 14
So is a drone weighing less than one pound and controlled by WiFi with a maximum range of 50 meters from the controller considered radio controlled? How about a toy helicopter using infra red with a range of maybe 20 meters? Like with the old gun laws - when does a toy become a gun or a gun become a toy. Until recently nobody could answer that. This new law is so ridiculous as to be unbelievable, even in the Philippines. It will certainly wipe out the model aircraft industry with many thousands of owners unable to use the models they spent large amounts of time and money on. Frank Woolf On Jul 28, 2014, at 9:56 AM, talk-ph-requ...@openstreetmap.org wrote: Message: 1 Date: Mon, 28 Jul 2014 01:19:35 +0800 From: Mark Cupitt markcup...@gmail.com To: osm-ph talk-ph@openstreetmap.org Subject: [talk-ph] Drones Message-ID: CACYK9T=6q6fe7mrpbx-d976sn6j5p5lo-oluzvo_pino7an...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Drone memo bugs plane hobbyists*By Eric B. Apolonio* | Jul. 28, 2014 at 12:01am http://manilastandardtoday.com/2014/07/28/drone-memo-bugs-plane-hobbyists# Hundreds of hobbyists ?piloting? radio-controlled airplanes will have to comply with the memorandum of the Civil Aviation and Authority of the Philippines on unmanned aircraft vehicle or pay a fine of up to P500,000 per flight. Capt. Beda Badiola, CAAP-Assistant Director General and head of Flight Standard Inspectorate Service, said the regulation also covered amateur videographers or photographers, researchers, geodetic survey firms and broadcast media. Even before drone became a byword especially in the military, remote-controlled planes have been a popular ?sport? among closely-knit circles of enthusiasts who have built and modified kits on scale aircraft from World War II-era T-28 Trojan ?Tora Tora? and B-25 Mitchell to the turbine-powered F-15 Eagle and F-22 Raptor fighter jet models. In December last year, modellers held the first Philippine R/C Aircraft Congress at the Angeles City Flying Club in Magalang, Pampanga, where flight manuevers included aerobatics in a mini-version of an international air show. Under Memorandum Circular 21 series of 2014 dated June 26, 2014, drone owners or operators are required to register and secure a certification to operate from the agency. To be certified as UAV controller, an applicant must qualify for a radio operator?s certificate of proficiency; have been awarded a passed rating in an aviation license theory examination; have been awarded a passed rating in an instrument theory examination;completed a training course on the operation of the type of UAV that he/she posses to operate; have at least five hours experience operating UAVs outside controlled airspace. The applicant must also obtain at least one of three certifications: Flight crew license with a command instrument training; Military qualification equivalent to a license; or Air traffic control license. The directive likewise requires a detailed description of the UAV and purpose for its use. Under Philippine Civil Aviation Regulations, ?any operators found violating rules will be fined between P300,000 to P500,000 per unauthorized flight depending on the grave of violations?. The circular also banned flying UAVs over populated places, restricted corridors such as Malaca?an Palace, airports and no-fly zones of military camps. The CAAP defines a Large UAV as unmanned airship with an envelope capacity greater than 100 cubic meters; a Micro UAV as UAV with a gross weight of 100 grams or less; and Small UAV as neither a large UAV nor a micro UAV Regards Mark Cupitt ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Sat, Jul 26, 2014 at 11:02 PM, Frederik Ramm frede...@remote.org wrote: Again and again we hear, make it easier for people to geocode their proprietary databases and OSM can only benefit from it because everyone who saves $$ using OSM somehow magically helps OSM. I'm not convinced of that. One could say the same about the permissive parts of OpenStreetMap today. But there are companies today who're using OpenStreetMap and who are playing an active role to improve the database directly or indirectly (think software, event sponsoring). Interestingly, I have yet to see a company that supports OpenStreetMap as a need of following the letter of the ODbL. There aren't exactly tons of announcements of new ODbL datasets. In addition, even if companies, non profit organizations or governments decide to use but not actively support OpenStreetMap at all, they typically bring OpenStreetMap to broad audiences at a time, and expose OpenStreetMap to more potential individual contributors. What I'm seeing is an attractive OpenStreetMap to participate in, with great reasons to contribute and a growing group of institutional data users with huge opportunities to do so - and already doing so. But right now we're stuck insisting in one very particular way to contribute - and that way isn't defined all too well and it impedes the use of OpenStreetMap for a key use case: geocoding. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Mon, Jul 28, 2014 at 7:30 AM, Paul Norman penor...@mac.com wrote: Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/ Geocoding_-_Guideline Alex, you mention it was based on what you've gotten from lawyers. Is there anything that can be shared, either publicly, or with the LWG for when they consider the guideline? Our lawyers' advice is captured in the guideline as shared and posted in this revision: https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelineoldid=1060775 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 28/lug/2014 um 09:07 schrieb Alex Barth a...@mapbox.com: Our lawyers' advice is captured in the guideline as shared and posted in this revision: your lawyers did really say according to their understanding a pair of coordinates is similar to an image or a video, hence a work? The whole interpretation in this example turns around this sentence but it isn't quite self explaining: The guideline Geocodes are a Produced Work by the definition of the ODbL (section 1.) cheers, Martin___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hello, 2014-07-28 7:19 GMT+02:00 Eric Gundersen e...@mapbox.com: Accuracy is what matters, not skimping on a few $. We have dozens of large companies like this that would love to more tightly integrate their internal data with OSM via goecoding, but because of unclear guidelines are blocked. Well, in fact (IMHO) there's no unclear guidelines, as the license is quite clear in terms of Derivative Database licensing. Whether or not is it is subject to change, at this moment (ODbL v1.0) a Derivative Database has to be an ODbL database. What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself Or, trying to consider a database with geocoding data a Produced Work makes me wonder what type of substantial (I guess we're talking country-wide at least?) extract of the whole database _isn't_ a Produced Work anymore. Regards, Tadeusz ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Mon, Jul 28, 2014 at 1:19 AM, Eric Gundersen e...@mapbox.com wrote: Let's not kid ourselves here. The overwhelming number of commercial OSM users are not driven by a motivation to help us, but by a motivation to save money (or perhaps a motivation to escape a monopolist's clutch but that boils down to the same). Frederik, saving money is not the point, it's all about having great data that is supported by a community. Every day I'm talking to commercial companies interested in _paying_ Mapbox because they truly believe we have the best map (power by OpenStreetMap), and the people at these companies believe in a future of open data where the map continues to grow thanks to being open. Mapbox is working with companies from foursquare to Pinterest to the Financial Times to VK.com (https://www.mapbox.com/showcase). These few sites alone are used by hundreds of millions of people looking at beautiful OpenStreetMap data, and location and thus the map, is critical for each app. Accuracy is what matters, not skimping on a few $. We have dozens of large companies like this that would love to more tightly integrate their internal data with OSM via goecoding, but because of unclear guidelines are blocked. +1 Any company I'm aware of interested in OSM is not trying to save money, they're interested in the promise of better quality that you get from a community (of individuals and companies if they're welcome). In fact many companies with plenty of money are hurting for the lack of a truly global geocoder. There is no single source for this, especially outside the US. Try to find one and pay them: you can't. To be clear: OSM is far from ready to provide a high-quality global geocoder. It works pretty well in NYC and I was glad to see how well it worked in Karlsruhe :) but there's a serious lack of address data globally. So the problem is not that it's a great source of geocoding data that we're prevented from using because of licensing. The problem is that there's about to be a lot of resources, effort, and attention focused on this problem, and it would be great to do this within OSM. There are alternatives though such as OpenAddresses. Back to my original comment, if it we're 2010 and I had significant resources to invest in this problem, where would I best do it? Again -- it's fine if it's not OSM, should just come out with a strong statement from the board either way. -Randy ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hi, On 07/28/2014 12:07 PM, Tadeusz Knapik wrote: What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself There's a couple sides to this. OSMF is limited to distributing the data under ODbL or CC-By-SA as per the contributor terms; using any other license would require a license change process as outlined in the contributor terms. Now where the ODbL leaves wriggle room, OSMF can to a certain degree interpret the license. Since OSMF are the ones who would have to sue you if you ignore the license, if OSMF say it is our interpretation that so-and-so is ok then you are relatively safe in trusting them. However, if OSMF were to take too many liberties in interpreting the license, and if someone were to make the point that what OSMF distributes the data under is not the ODbL as it was intended, but instead some ODbL with OSMF bells and whistles, then that could nullify the license that OSMF itself has been granted by the mappers. It is quite possible that a lawyer who was asked to assert whether a certain wriggle room exists or not, would not only look at the letter of the license but also at the process that has led to its implementation, or in other words, at the intention that people had when they implemented the license. And that, in turn, is probably why we're talking so much about use cases and do-we-want-this and do-we-want-that... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On 7/28/2014 6:31 AM, Frederik Ramm wrote: Hi, On 07/28/2014 12:07 PM, Tadeusz Knapik wrote: What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself There's a couple sides to this. OSMF is limited to distributing the data under ODbL or CC-By-SA as per the contributor terms; using any other license would require a license change process as outlined in the contributor terms. It's also important to remember that there is also a significant amount of third-party data in OSM under the ODbL or compatible licenses, and the OSMF's guidelines are of limited influence there. This is one reason why I was particularly concerned when companies were failing to meet ODbL attribution requirements[1], as it wasn't just OSM contributor rights which were being infringed, but also the third party rights. [1]: http://wiki.osmfoundation.org/wiki/Board_Meeting_Minutes_2013-12-10#6._Attribution ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I would like to add my voice to this discussion. I strongly believe that within the intended spirit of the OSM license, geocoding as defined in this proposal should _not_ trigger share alike. I also believe that the legal interpretation proposed has merit, but if legal advice suggests another means in which to capture this spirit, I would support that as well. As a former OSMF Board member and a member of the OSM community for 9 years, I believe my voice should carry weight in this discussion. Other current and former Board members, and prominent members of the OSM community, have also lent their weighty voices to this discussion. That's excellent, this is the purpose of legal-talk, it has been very enlightening on this issue. But what discussion on legal-talk does not provide is a mechanism for ascertaining a representative community opinion on the spirit of the license; nor a legally qualified opinion on interpretation options; nor a governance mechanism for resolving the proposal ultimately one way or another. I'm not aware if any process is defined for making a decision on this use case. (If one does exist, apologies that I missed it, and I'd appreciate anything that could bring clarity.) The OpenStreetMap Foundation, famously, supports but does not control the OpenStreetMap project. In this situation, I believe this would mean devising a governance structure to help answer such questions, and request that the OSMF in one form or another prioritize this issue. I hope that such can take shape soon, so that the topic of geocoding and other topics can be efficiently and finally resolved. Sincerely Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron On Thursday, July 24, 2014 5:04 PM, Alex Barth a...@mapbox.com wrote: On Sat, Jul 12, 2014 at 2:30 AM, Paul Norman penor...@mac.com wrote: Consider a chain retailer's database of store locations with store names and addresses (street, house number, ZIP, state/province, country). The addresses are used to search corresponding latitude / longitude coordinates in OpenStreetMap. The coordinates are stored next to the store locations in the store database (forward Geocoding). OpenStreetMap.org's Nominatim based geocoder is used. The store locations are being exposed to the public on a store locator map using Bing maps. The geocoded store locations database remains fully proprietary to the chain retailer. The map carries a notice (c) OpenStreetMap contributors linking to http://www.openstreetmap.org/copyright. In this example, the database powering the geocoder is a derived database. The geocoding results are produced works, which are then collected into what forms a derivative database as part of a collective database. Not following how I can make a Derivative Database from a Produced Work. Once it's a Produced Work it's a Produced Work, right? Sure if I abuse to recreate OSM that's one thing, but at this level? Taking a step back, is the above use case not one we'd like to support without triggering share alike? I'm directing my question to everyone, not just Paul who's taken the time to review my example above. Forward and reverse geocoding existing records is such a huge potential use case for OSM, helping us drive contributions. At the same time it's _the_ use case of OSM where we collide heads on with the realities and messiness of data licensing: Do we really want to make a legal review the hurdle of entry for using OSM for geocoding? Or limit using OSM for geocoding in areas where no one's ever going to sue? How can we get on the same page on how we want geocoding to work and then trace back on how we can fit this into the ODbL? Geocoding should just be possible and frictionless with OSM, no? Shouldn't there be a way to open up OSM to geocoding while maintaining share alike on the whole database? I feel we don't get anywhere by reading the tea leaves of the ODbL - what do we really want for OSM on geocoding? Alex (and yes, when I'm saying geocoding I'm referring to permanent geocoding here, where the geocoding result winds up being stored in someone else's db) ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I would like to add my voice to this discussion. I strongly believe that within the intended spirit of the OSM license, geocoding as defined in this proposal should _not_ trigger share alike. I also believe that the legal interpretation proposed has merit, but if legal advice suggests another means in which to capture this spirit, I would support that as well. As a former OSMF Board member and a member of the OSM community for 9 years, I believe my voice should carry weight in this discussion. Other current and former Board members, and prominent members of the OSM community, have also lent their weighty voices to this discussion. That's excellent, this is the purpose of legal-talk, it has been very enlightening on this issue. But what discussion on legal-talk does not provide is a mechanism for ascertaining a representative community opinion on the spirit of the license; nor a legally qualified opinion on interpretation options; nor a governance mechanism for resolving the proposal ultimately one way or another. I'm not aware if any process is defined for making a decision on this use case. (If one does exist, apologies that I missed it, and I'd appreciate anything that could bring clarity.) The OpenStreetMap Foundation, famously, supports but does not control the OpenStreetMap project. In this situation, I believe this would mean devising a governance structure to help answer such questions, and request that the OSMF in one form or another prioritize this issue. I hope that such can take shape soon, so that the topic of geocoding and other topics can be efficiently and finally resolved. Sincerely Mikel ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] [Talk-us] IR boundary tagging
On Sun, Jul 27, 2014 at 10:28 PM, Greg Morgan dr.kludge...@gmail.com wrote: I'd say make the changes at the city admin level for these reasons. The tribal nations are viewed by the courts as territories but they tend to act more at the city[4] to county[3] COG [1] level. The squabbles feel more like cities fighting over annexation issues or building alliances for or against economic development[4]. Based on Paul Norman's nice visualization [2] a city boundary feels like the correct admin level verses cutting areas out of county or state levels. Scottsdale cannot grow to the east[5] and Phoenix cannot grow to the south[6] as if the tribal nations are cities. The tribal nations still have to act at or below the county level to get things done[1][3]. Tribal lands are not cities. Well some are, but only because they are a city. But most cover large geographical territories. Categorizing tribal lands as city or county, IMHO, is wrong. The reservations are not State (US State) controlled lands. However they do work in partnership with the states and counties on many fronts. Native American people have dual citizenship. Where they live determines who they can vote for in US elections. So where the people reside determines where they vote. The problem is the admin level boundary doesn't work for tribal lands. From previous discussions I understood that we agreed that boundary=aboriginal_lands was probably the most suitable compromise. The boundary shows tribal lands and the states and county boundaries show where people vote. Paul Johnson, I emphasize with you, but I don't see how we can accommodate Domestic Dependant States in the current admin hierarchy. boundary=aboriginal_lands. I just fixed a boundary for the Swinomish Tribe nearby. The previous boundary cut right through their casino property. Plus the old boundary did not include their water rights. I'd like to do an import of Washington Tribal lands in the near future. Only a small number are in OSM. It would be great if we could agree on a tagging structure. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Announcing the MapRoulette mailing list
Hi all, MapRoulette, the game-like bug fixing tool that most of you have heard of, now has its own mailing list. You can subscribe at https://lists.openstreetmap.org/listinfo/maproulette For now, this list will cover both general user level discussion as well as development topics. So whether you want to discuss your idea for a new challenge, start contributing to the code, or you have a question on how to use MapRoulette, this list will be a great start. Please do not use the new MapRoulette mailing list for bug reports. These are best filed (and discussed) at the MapRoulette source code repository on Github: https://github.com/osmlab/maproulette/issues Thanks for your continued interest in MapRoulette! -- Martijn van Exel ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Recently I saw anonymous notes being added of the form Incorrect speed limit. Reported speed limit is X km/h. Here's a search query: http://api.openstreetmap.org/api/0.6/notes/search?q=Incorrect%20speed%20limit.%20Reported%20speed%20limit%20is As they all are generated from a template, I guess this is some app which allows users to report back errors. But it remains a mystery: Who is author of this software? As you can see, there are quite a lot of 0 km/h notes, so I am not particularly enthusiastic about validity of the data. I would rather suggest that the author either made an account for their app or otherwise stated in the body of a note. And for goodness' sake, validate what your users input against obvious errors ;-) Cheers, Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
On 28/07/14 23:38, Michał Brzozowski wrote: Recently I saw anonymous notes being added of the form Incorrect speed limit. Reported speed limit is X km/h. Here's a search query: http://api.openstreetmap.org/api/0.6/notes/search?q=Incorrect%20speed%20limit.%20Reported%20speed%20limit%20is As they all are generated from a template, I guess this is some app which allows users to report back errors. But it remains a mystery: Who is author of this software? As you can see, there are quite a lot of 0 km/h notes, so I am not particularly enthusiastic about validity of the data. I would rather suggest that the author either made an account for their app or otherwise stated in the body of a note. And for goodness' sake, validate what your users input against obvious errors ;-) Those notes do all appear to be coming from one source - I have sent them an email to try and make contact with somebody so we can discuss how they can improve things. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Interesting. The coverage of these notes is almost global. I don't see any in South America or Australia but otherwise there are some on each continent. I also see some reported speed limits in the U.S. in km/h which is most likely not correct. Once upon a time I suggested adding a kind of created_by type of field to notes that would eventually be required for 3rd party applications posting anonymous notes. But it seems no code has magically appeared to do this yet. Toby On Mon, Jul 28, 2014 at 5:38 PM, Michał Brzozowski www.ha...@gmail.com wrote: Recently I saw anonymous notes being added of the form Incorrect speed limit. Reported speed limit is X km/h. Here's a search query: http://api.openstreetmap.org/api/0.6/notes/search?q=Incorrect%20speed%20limit.%20Reported%20speed%20limit%20is As they all are generated from a template, I guess this is some app which allows users to report back errors. But it remains a mystery: Who is author of this software? As you can see, there are quite a lot of 0 km/h notes, so I am not particularly enthusiastic about validity of the data. I would rather suggest that the author either made an account for their app or otherwise stated in the body of a note. And for goodness' sake, validate what your users input against obvious errors ;-) Cheers, Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
They also appear in French: Limitation de vitesse inappropriée. La limitation de vitesse signalée est X km/h And in Portugese: Limite de velocidade incorreto. O limite de velocidade informado é X km/h also Finnish, Czech, Swedish, Italian... Oh, you can just view all of them by searching km/h :) http://api.openstreetmap.org/api/0.6/notes/search?q=km/h They seem to translate these into the country's language and fall back to English in case of unavailable translation. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
I'm from Brazil, and recently the community started reporting similar notes, though translated in portuguese, and with the same problems... Besides some obviously wrong values, there are some you can't even say where exactly they would apply to. There's been at least some 60 of those in portuguese so far. I saw a similar note in Spanish too, so they are probably even more widespread... Besides the report of speed limit, I also saw some Can't turn left. note[1], which are likely to be from the same origin. Agree with all Michał said. [1]: http://www.openstreetmap.org/note/205281 Em 28/07/2014 20:16, Toby Murray toby.mur...@gmail.com escreveu: Interesting. The coverage of these notes is almost global. I don't see any in South America or Australia but otherwise there are some on each continent. I also see some reported speed limits in the U.S. in km/h which is most likely not correct. Once upon a time I suggested adding a kind of created_by type of field to notes that would eventually be required for 3rd party applications posting anonymous notes. But it seems no code has magically appeared to do this yet. Toby On Mon, Jul 28, 2014 at 5:38 PM, Michał Brzozowski www.ha...@gmail.com wrote: Recently I saw anonymous notes being added of the form Incorrect speed limit. Reported speed limit is X km/h. Here's a search query: http://api.openstreetmap.org/api/0.6/notes/search?q=Incorrect%20speed%20limit.%20Reported%20speed%20limit%20is As they all are generated from a template, I guess this is some app which allows users to report back errors. But it remains a mystery: Who is author of this software? As you can see, there are quite a lot of 0 km/h notes, so I am not particularly enthusiastic about validity of the data. I would rather suggest that the author either made an account for their app or otherwise stated in the body of a note. And for goodness' sake, validate what your users input against obvious errors ;-) Cheers, Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Digitale kaart toont live situatie rampgebied MH17
Ter info: http://webwereld.nl/big-data/83368-digitale-kaart-toont-live-situatie-rampgebied-mh17 Plattegrond op basis van Google: http://liveuamap.com/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] reverting changeset
Seccionar o trecho sem saída - obrigatoriamente de mão dupla - e marcá-lo com oneway=no. Em 28/07/2014 10:40, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: De outro modo, o que deve ser feito para corrigi-la? Em 28 de julho de 2014 09:10, thunder...@gpsinfo.com.br escreveu: É quando uma via de sentido único (mão única) não tem saída. Muitos inserem oneway=yes para uma via e deixam de verificar se no lado final daquele sentido existe saída. Em não existindo o roteamento nunca passará por aquela via uma vez que não existe continuidade. Na inúmeras correções que andei fazendo ontem identifiquei que muitas se devem a não existir a perfeita ligação de uma via oneway com outra via. Dessa forma aquela via é vista como “sem saída”. *From:* Alexandre Magno Brito de Medeiros alexandre@gmail.com *Sent:* Monday, July 28, 2014 8:46 AM *To:* OpenStreetMap no Brasil talk-br@openstreetmap.org *Subject:* Re: [Talk-br] reverting changeset Eu também não sei. Em 28 de julho de 2014 02:15, Márcio Vinícius Pinheiro marcioviniciu...@gmail.com escreveu: Perdoe minha ignorância, mas só por curiosidade, o que exatamente é um erro de ambiguidade oneway? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
Sim, se o trecho dado como sem saída não o é de fato. Em 28/07/2014 11:37, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Ou conectar em outra extremidade. Nem sempre q isso acontecer deve colocar oneway=no Em 28/07/2014 11:16, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Seccionar o trecho sem saída - obrigatoriamente de mão dupla - e marcá-lo com oneway=no. Em 28/07/2014 10:40, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: De outro modo, o que deve ser feito para corrigi-la? Em 28 de julho de 2014 09:10, thunder...@gpsinfo.com.br escreveu: É quando uma via de sentido único (mão única) não tem saída. Muitos inserem oneway=yes para uma via e deixam de verificar se no lado final daquele sentido existe saída. Em não existindo o roteamento nunca passará por aquela via uma vez que não existe continuidade. Na inúmeras correções que andei fazendo ontem identifiquei que muitas se devem a não existir a perfeita ligação de uma via oneway com outra via. Dessa forma aquela via é vista como “sem saída”. *From:* Alexandre Magno Brito de Medeiros alexandre@gmail.com *Sent:* Monday, July 28, 2014 8:46 AM *To:* OpenStreetMap no Brasil talk-br@openstreetmap.org *Subject:* Re: [Talk-br] reverting changeset Eu também não sei. Em 28 de julho de 2014 02:15, Márcio Vinícius Pinheiro marcioviniciu...@gmail.com escreveu: Perdoe minha ignorância, mas só por curiosidade, o que exatamente é um erro de ambiguidade oneway? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
Parece que o mesmo usuário está criando notas com outra variação: Proibido virar à esquerda. Encontrei duas: http://www.openstreetmap.org/note/205281 http://www.openstreetmap.org/note/207184 2014-07-25 22:19 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Hahaha vlw. Em 25/07/2014 22:18, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Resolve. http://www.openstreetmap.org/note/205250 Eles cansam! E eu formataria uma mensagem padrão tentando sensibilizar quem persista ao ponto de monitorar o próprio SPAM. Um desgraçado desses, se não estiver sendo pago, um dia se arrepende de ser mau. 2014-07-25 20:49 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Um usuário está criando notas spam. O que pode ser feito? Ou nada? rs http://www.openstreetmap.org/note/205279 http://www.openstreetmap.org/note/205275 http://www.openstreetmap.org/note/205273 http://www.openstreetmap.org/note/205262 http://www.openstreetmap.org/note/205261 http://www.openstreetmap.org/note/205250 http://www.openstreetmap.org/note/205235 http://www.openstreetmap.org/note/205220 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
é anônimo. Em 28 de julho de 2014 11:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
2014-07-28 11:59 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é anônimo. É... percebi isso depois. Parece que preciso tomar mais café :-) Mas mesmo assim, talvez ele não esteja apenas colocando as notas em local errado? Eu acho difícil alguém perder tempo falando que a velocidade de uma via é X Km/h. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
É anônimo, mas não necessariamente o mesmo anônimo. Podem ser pessoas diferentes. Sugiro acrescentar uma mensagem na nota assim Obrigado por sua contribuição. Porque não cria um cadastro? Assim podemos entrar em contato em caso de dúvidas. abraço Gerald 2014-07-28 11:59 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é anônimo. Em 28 de julho de 2014 11:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
Se observar o histórico com certeza eh o mesmo filho da mae. Ele ou ta sacaneando ou ta testando alguma coisa se a houver uma API d notas. Em 28/07/2014 12:25, Gerald Weber gwebe...@gmail.com escreveu: É anônimo, mas não necessariamente o mesmo anônimo. Podem ser pessoas diferentes. Sugiro acrescentar uma mensagem na nota assim Obrigado por sua contribuição. Porque não cria um cadastro? Assim podemos entrar em contato em caso de dúvidas. abraço Gerald 2014-07-28 11:59 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é anônimo. Em 28 de julho de 2014 11:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
Caramba..desenhar uma rua, sem saída e colocar como mão única é mandar o cara pro inferno,não tem navegador ali que vá fazer retorno...rsr, se deixa sem tag alguma,a maioria das TTS de hje taxam esse trecho com Beco.. Mas, na lista de erros que tem lá, o grosso que estou achando lá, é rotatória meia volta, sentido esquerdo e meia volta sentido direito..(é pra ficar loco...ou mesmo rotatória toda na contra-mão( esquerda) acho que algum inglês andou desenhando ali...rsrs ___ Anor C. A. de Souza Concórdia SC 49-8808-4963 Date: Mon, 28 Jul 2014 11:39:32 -0300 From: openstreet...@arlindopereira.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] reverting changeset Sim, se o trecho dado como sem saída não o é de fato. Em 28/07/2014 11:37, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Ou conectar em outra extremidade. Nem sempre q isso acontecer deve colocar oneway=no Em 28/07/2014 11:16, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Seccionar o trecho sem saída - obrigatoriamente de mão dupla - e marcá-lo com oneway=no. Em 28/07/2014 10:40, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: De outro modo, o que deve ser feito para corrigi-la? Em 28 de julho de 2014 09:10, thunder...@gpsinfo.com.br escreveu: É quando uma via de sentido único (mão única) não tem saída. Muitos inserem oneway=yes para uma via e deixam de verificar se no lado final daquele sentido existe saída. Em não existindo o roteamento nunca passará por aquela via uma vez que não existe continuidade. Na inúmeras correções que andei fazendo ontem identifiquei que muitas se devem a não existir a perfeita ligação de uma via oneway com outra via. Dessa forma aquela via é vista como “sem saída”. From: Alexandre Magno Brito de Medeiros Sent: Monday, July 28, 2014 8:46 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] reverting changeset Eu também não sei. Em 28 de julho de 2014 02:15, Márcio Vinícius Pinheiro marcioviniciu...@gmail.com escreveu: Perdoe minha ignorância, mas só por curiosidade, o que exatamente é um erro de ambiguidade oneway? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
Certamente há notas que são SPAM, como aquelas Velocidade máxima 0 Km. Também pode haver notas legítimas fora de lugar. Infelizmente a API não fornece informações tais como IP de origem. Ex.: http://api.openstreetmap.org/api/0.6/notes/205281 Em 28 de julho de 2014 12:32, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Se observar o histórico com certeza eh o mesmo filho da mae. Ele ou ta sacaneando ou ta testando alguma coisa se a houver uma API d notas. Em 28/07/2014 12:25, Gerald Weber gwebe...@gmail.com escreveu: É anônimo, mas não necessariamente o mesmo anônimo. Podem ser pessoas diferentes. Sugiro acrescentar uma mensagem na nota assim Obrigado por sua contribuição. Porque não cria um cadastro? Assim podemos entrar em contato em caso de dúvidas. abraço Gerald 2014-07-28 11:59 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é anônimo. Em 28 de julho de 2014 11:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
Isto http://forum.openstreetmap.org/viewtopic.php?pid=440139#p440139 pode ajudar: - Roundabouts_BRA - lista *HTML https://rawgit.com/alexandre-mbm/87deea7ca534a913a985/raw/8dd2ebab26f47e145ed54189365a9ed44556a227/Roundabouts_BRA.html* Vou incluir os intervalos em WikiProject Brazil/Manutenção COCAR https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Manuten%C3%A7%C3%A3o_COCAR . Alexandre Magno Em 28 de julho de 2014 13:15, A. Carlos anorcar...@hotmail.com escreveu: Mas, na lista de erros que tem lá, o grosso que estou achando lá, é rotatória meia volta, sentido esquerdo e meia volta sentido direito..(é pra ficar loco...ou mesmo rotatória toda na contra-mão( esquerda) acho que algum inglês andou desenhando ali...rsrs ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
O sentido que faz é deixar facilitado para quem quiser atuar nisso. Grifo meu: *Fiz o download do arquivo de erros do mapa do Brasil e fiquei impressionado com a quantidade de erros apontada. Até já andei corrigindo alguns erros, mas a quantidade de erros a corrigir é muito grande e se torna necessário que mais elementos se juntem nessa ação ou apontem para um método mais simples de identificação e correção. *-- Thundercel, em Inconsistências no mapa http://forum.openstreetmap.org/viewtopic.php?id=26466 Parece que vocês todos valorizam roteamento, e eu muito pouco (para as minhas mãos). Mas sei que é importante! Estou tentando dar alguma contribuição, tentando apresentar alguma facilitação. Alexandre Magno Em 28 de julho de 2014 14:07, Nelson A. de Oliveira nao...@gmail.com escreveu: Desculpa ser chato nisso, mas alguém vai verificar e arrumar esses erros e avisos? Senão não faz sentido gerar listas de melhorias ou correções. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
2014-07-28 14:17 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Fiz o download do arquivo de erros do mapa do Brasil e fiquei impressionado com a quantidade de erros apontada. Até já andei corrigindo alguns erros, mas a quantidade de erros a corrigir é muito grande e se torna necessário que mais elementos se juntem nessa ação ou apontem para um método mais simples de identificação e correção. -- Thundercel, em Inconsistências no mapa O problema não é achar os erros, mas ter quem arruma. Esses erros do mkgmap eu arrumo de vez em quando no estado de SP, por exemplo, mas é trabalho sem fim. Nunca diminuem. A não ser que a lista seja sempre atualizada e que sempre exista alguém olhando esses erros, não faz sentido. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
Em 28 de julho de 2014 14:22, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-07-28 14:17 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Fiz o download do arquivo de erros do mapa do Brasil e fiquei impressionado com a quantidade de erros apontada. Até já andei corrigindo alguns erros, mas a quantidade de erros a corrigir é muito grande e se torna necessário que mais elementos se juntem nessa ação ou apontem para um método mais simples de identificação e correção. -- Thundercel, em Inconsistências no mapa O problema não é achar os erros, mas ter quem arruma. São dois problemas. A não ser que a lista seja sempre atualizada e que sempre exista alguém olhando esses erros, não faz sentido. Os comandos que foram usados para gerar as listas poderão ser aproveitados e melhorados (ou substituídos) em geradores automáticos. Ou a lógica deles. Um sistema web poderá se encarregar de fazer uma publicação organizada e sempre atualizada. Essas melhorias, por enquanto, eu vou deixando para quem se interessar mais do que eu. Tudo que eu tenho usado está em aqui: gist.github.com/alexandre-mbm/87deea7ca534a913a985. A página não lista todos os arquivos. Os scripts estão ocultos. Clone o repositório e os verá. São *scripts* de uma linha. Alexandre Magno ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
2014-07-28 14:29 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: São dois problemas. Não é. Acontece que quem quer corrigir os erros vai atrás. Não adianta gerar lista ou falar precisamos arrumar tal coisa que ninguém se dispõe. É o que já acontece com tudo o que falta fazer no Brasil: traçar rodovias, traçar cidades, colocar nome de ruas, etc. Todo mundo aqui já sabe, de certa forma, o que precisa ser feito. Falta tempo, pessoas, ânimo... ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] reverting changeset
Nelson A. de Oliveira Todo mundo aqui já sabe, de certa forma, o que precisa ser feito. Falta tempo, pessoas, ânimo... Estamos trabalhando junto a comunidade que emprega GPS e garimpando novos colaboradores. Como todos sabem quem emprega GPS muito se preocupa com o roteamento e um mapa com inúmeros erros que interferem no roteamento não é admirado e tampouco empregado por esses. Dificilmente esses irão colaborar porque não empregando o mapa em seus GPS não identificarão melhorias. A bola da vez no Brasil é o emprego do smartphone para navegação e estamos fazendo divulgação maciça de APPs que podem empregar o mapa Cocar que advém da base OSM. Esperamos com essa ação também motivar o pessoal para nos ajudar no mapa. Pelo menos eu me comprometo a todo dia fazer algumas correções dos erros de forma a melhorar o roteamento, entretanto volto a citar que esse árduo trabalho corrige os existentes. Os que irão surgir aponta ser]ao minimizados, na minha opinião, se algo for feito no validador impedindo a inserção da grande maioria deles. Como não entendo nada de programação deixo essa ação para os experts'. []s Marcio ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Spam nas notas
Parece que é alguém fazendo isso globalmente, estão discutindo o assunto na talk@ pois há notas semelhantes em inglês e outros idiomas em todo o mundo. []s Arlindo 2014-07-28 13:24 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Certamente há notas que são SPAM, como aquelas Velocidade máxima 0 Km. Também pode haver notas legítimas fora de lugar. Infelizmente a API não fornece informações tais como IP de origem. Ex.: http://api.openstreetmap.org/api/0.6/notes/205281 Em 28 de julho de 2014 12:32, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Se observar o histórico com certeza eh o mesmo filho da mae. Ele ou ta sacaneando ou ta testando alguma coisa se a houver uma API d notas. Em 28/07/2014 12:25, Gerald Weber gwebe...@gmail.com escreveu: É anônimo, mas não necessariamente o mesmo anônimo. Podem ser pessoas diferentes. Sugiro acrescentar uma mensagem na nota assim Obrigado por sua contribuição. Porque não cria um cadastro? Assim podemos entrar em contato em caso de dúvidas. abraço Gerald 2014-07-28 11:59 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é anônimo. Em 28 de julho de 2014 11:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Mas é spam mesmo ou ele só está marcando as notas em local errado? Alguém já mandou mensagem para ele? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] OSM: Es entwickelt sich!
OSM-Daten im Vergleich: 2007 und heute. Hut ab! Und so können wir alle ein bißchen stolz sein. http://mvexel.github.io/thenandnow/#11/51.4440/11.8783 http://geoobserver.wordpress.com/2014/07/28/osm-es-entwickelt-sich/ mikeE. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: ein bißchen Statistik
Hallo Pascal und Werner Habt ihr schon erste Schlussfolgerungen, was die Statistiken aussagen? Bei beiden wird offenbar ein exponentielles Wachstum angenommen, oder? Denn bei Werner's Statistik werden doppelt logarithmische Skalen angewendet und Pascal kumulierte die Objekte (= 100%). Bei Werner's ersten beiden Grafiken könnte die These interessant sein, ob neue User weniger Objekte Mappen(?). Bei Pascals erster interessanter Grafik, würde ich folgern, dass 2014 signifikant weniger neue Nodes (von 2014 ~17% auf 2014 ~12%) erzeugt wurden(?). Pascals zweiter Grafik mit dem Durchschnittsalter von OSM Objekten scheint mir die Frage zugrunde zu liegen, ob die Mapper tendenziell häufiger aktualisieren? Ich habe jedenfalls Mühe nachzuvollziehen, 1. was die Grafik aussagt und 2. wie die Aussage 55% of the Nodes, 67% of the Ways and 74% of the Relations in the OSM database do not have a timestamp dated before 2012 in der Grafik zu sehen ist, bzw. zustande kommt? --Stefan Am 27. Juli 2014 22:08 schrieb Werner Hoch werner...@gmx.de: Hi, spiele seit längerem mit ähnlichen Statistiken: http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html Die Daten sind vom April. mfg Werner Am Dienstag, den 22.07.2014, 06:36 + schrieb Elstermann, Mike: Dank Pascal Neis können wir uns wieder auf eine kurzweilige und interessante OSM-Statistik freuen... Danke dafür! http://neis-one.org/2014/07/age-of-osm-objects/ oder http://geoobserver.wordpress.com/2014/07/22/osm-ein-bischen-statistik/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: ein bißchen Statistik
Ich denke eine konkrete Interpretation des Userverhaltens ohne die jeweils grossen Importe rauszurechnen vermutlich zum Scheitern verurteilt ist (z.B. cadastre in FR). Simon Am 28.07.2014 08:53, schrieb Stefan Keller: Hallo Pascal und Werner Habt ihr schon erste Schlussfolgerungen, was die Statistiken aussagen? Bei beiden wird offenbar ein exponentielles Wachstum angenommen, oder? Denn bei Werner's Statistik werden doppelt logarithmische Skalen angewendet und Pascal kumulierte die Objekte (= 100%). Bei Werner's ersten beiden Grafiken könnte die These interessant sein, ob neue User weniger Objekte Mappen(?). Bei Pascals erster interessanter Grafik, würde ich folgern, dass 2014 signifikant weniger neue Nodes (von 2014 ~17% auf 2014 ~12%) erzeugt wurden(?). Pascals zweiter Grafik mit dem Durchschnittsalter von OSM Objekten scheint mir die Frage zugrunde zu liegen, ob die Mapper tendenziell häufiger aktualisieren? Ich habe jedenfalls Mühe nachzuvollziehen, 1. was die Grafik aussagt und 2. wie die Aussage 55% of the Nodes, 67% of the Ways and 74% of the Relations in the OSM database do not have a timestamp dated before 2012 in der Grafik zu sehen ist, bzw. zustande kommt? --Stefan Am 27. Juli 2014 22:08 schrieb Werner Hoch werner...@gmx.de: Hi, spiele seit längerem mit ähnlichen Statistiken: http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html Die Daten sind vom April. mfg Werner Am Dienstag, den 22.07.2014, 06:36 + schrieb Elstermann, Mike: Dank Pascal Neis können wir uns wieder auf eine kurzweilige und interessante OSM-Statistik freuen... Danke dafür! http://neis-one.org/2014/07/age-of-osm-objects/ oder http://geoobserver.wordpress.com/2014/07/22/osm-ein-bischen-statistik/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Liste gestört?
Hallo, auf meiner Seite wurde nichts geändert, aber seit dem 18.7. kam keine Listenmail mehr herein. Ist gerade Sommerpause? Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste gestört?
Also bei mir funktioniert noch alles: http://i.imgur.com/myXFAd7.png (Die Mails geht aber nicht an meine Emailadresse sondern kommen von dem gmane.org, vielleicht liegt es daran?) Hallo, auf meiner Seite wurde nichts geändert, aber seit dem 18.7. kam keine Listenmail mehr herein. Ist gerade Sommerpause? Gruß Andreas __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] CBI google maps
He he.., It seems that SOI has no problems if google privately having our country's geospatial data (That is always subject to the verification by NSA, FBI or whatever). But if google publish the same in the web through their mapping services, as that may become helpful for different stakeholders of this country at various levels, that would be considered as a serious sin. Also, SOI is not interested / don't have ability to disseminate the data it holds, for any useful purpose for the general public of this country. Sounds nice, right? :) 2014-07-27 19:32 GMT+05:30 Sajjad Anwar m...@sajjad.in: My thoughts are not very strong but, I think as long as we leave the vital points and defense installations out of the map, we won't grab much attention. Through Datameet and NIC, some of us are trying to setup a meeting with a few SoI officials to talk about opening up some data. More about that soon, when something concrete comes up. Cheers, Sajjad. On Sun, Jul 27, 2014 at 7:27 PM, Paramvir Singh paramvi...@gmail.com wrote: What does it mean to OSM? Any experts? Sent from my BlackBerry 10 smartphone. *From: *Deepak Cherian *Sent: *Sunday, 27 July 2014 7:17 PM *To: *talk-in@openstreetmap.org *Reply To: *OpenStreetMap in India *Subject: *[Talk-in] CBI google maps Have you guys seen this? http://www.thehindu.com/sci-tech/technology/internet/google-mapping-comes-under-cbi-scrutiny/article6254654.ece?homepage=true The internet giant had not taken permission from Survey of India, country’s official mapping agency, before organising a mapping competition in February-March 2013 when they asked citizens to map their neighbourhoods, especially details related to hospitals and restaurants. Deepak ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Sajjad Anwar http://geohacker.in http://sajjad.in/ ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ - ജയ്സെനോവ് നെടുമ്പാലോവിച്ച് പഹയനോവ്സ്കി - ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ (`'·.¸(`'·.¸^¸.·'´)¸.·'´) «´¨`·* . Jaisenov. *..´¨`» (¸.·'´(`'·.¸ ¸.·'´)`'·.¸) ¸.·´^.`'·.¸ ¸.·'´ ( `·.¸`·.¸ `·.¸ )`·.¸ ¸.·(´ `·.¸ ¸.·(.·´)`·.¸ ( `v´ ) `v´ ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
[Talk-at] Damals und heute
Nicht schlecht (2007 vs heute): http://mvexel.github.io/thenandnow/#11/48.1789/16.3573 /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
Hallo, da ist gerade ein eigenartiges Mapping der Gehwege als Flächen mit (aus meiner Sicht) fragwürdigen Multipolygon-Konstruken in Wien zwischen Kärntner Ring / Karlsplatz und Kärntner Straße / Schwarzenbergplatz im Gange. Zwischen Kärntner Ring und Bösendorfer Straße ist die Gehweg-Fläche sogar über den ganzen Gebäudekomplex gestülpt: http://www.openstreetmap.org/#map=18/48.20124/16.37208layers=N Was sagt ihr dazu, macht das generell (abgesehen vom offensichtlichen Fehler) Sinn? Was soll man mit diesen Edits am besten machen? LG aus 1080 Tom___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
Das hier scheint das Changeset zu sein: http://www.openstreetmap.org/changeset/22826275 Am 28.07.2014 um 20:03 schrieb Thomas Konrad tkon...@gmx.net: Hallo, da ist gerade ein eigenartiges Mapping der Gehwege als Flächen mit (aus meiner Sicht) fragwürdigen Multipolygon-Konstruken in Wien zwischen Kärntner Ring / Karlsplatz und Kärntner Straße / Schwarzenbergplatz im Gange. Zwischen Kärntner Ring und Bösendorfer Straße ist die Gehweg-Fläche sogar über den ganzen Gebäudekomplex gestülpt: http://www.openstreetmap.org/#map=18/48.20124/16.37208layers=N Was sagt ihr dazu, macht das generell (abgesehen vom offensichtlichen Fehler) Sinn? Was soll man mit diesen Edits am besten machen? LG aus 1080 Tom ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
On 07/28/2014 08:03 PM, Thomas Konrad wrote: Was sagt ihr dazu, macht das generell (abgesehen vom offensichtlichen Fehler) Sinn? Was soll man mit diesen Edits am besten machen? Ich halte das separate Mappen von Gehsteigen mit eigenem, parallelem footway routingtechnisch ohnehin für problematisch. Wenn die jetzt als Flächen gezeichnet (ich möchte das nichtmal mappen nennen) werden, dann hat sich das Routing dort ohnehin erledigt. Ich hab einerseits kein Problem damit, dass wir dieses - in meinen Augen - unausgereifte Gehsteigmapping durch derartige Edits komplett ad absurdum führen, aber andrerseits muss man schon sagen, dass derartiges Editieren nur noch nutzlos ist, und der User genauso gut ein beliebiges Zeichenprogramm öffnen könnte um dort den Mapnik Stil zu verbessern. Imo ist das Müll und ich würd den Edit reverten. Es entspricht keiner gängigen Mappingpraxis (zumindest keiner die ich kenn) und bringt in den Daten genau keinen Mehrwert. Ich würd das einfach als Fehler ansehen und genauso behandeln. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
Im Prinzip hast du Recht aber bitte nicht zu dem Nutzer selbst so garstig sein wenn man's ihm Erklärt da er sich laut Profil noch immer als Neuling fühlt ( http://www.openstreetmap.org/user/Railjet ). Wenn man ihm Erklärt warum das nicht sinnvoll ist usw. wird er es hoffentlich verstehen und in Zukunft diese Fehler nicht mehr machen. mfg eest9 Am 28. Juli 2014 22:17 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: On 07/28/2014 08:03 PM, Thomas Konrad wrote: Was sagt ihr dazu, macht das generell (abgesehen vom offensichtlichen Fehler) Sinn? Was soll man mit diesen Edits am besten machen? Ich halte das separate Mappen von Gehsteigen mit eigenem, parallelem footway routingtechnisch ohnehin für problematisch. Wenn die jetzt als Flächen gezeichnet (ich möchte das nichtmal mappen nennen) werden, dann hat sich das Routing dort ohnehin erledigt. Ich hab einerseits kein Problem damit, dass wir dieses - in meinen Augen - unausgereifte Gehsteigmapping durch derartige Edits komplett ad absurdum führen, aber andrerseits muss man schon sagen, dass derartiges Editieren nur noch nutzlos ist, und der User genauso gut ein beliebiges Zeichenprogramm öffnen könnte um dort den Mapnik Stil zu verbessern. Imo ist das Müll und ich würd den Edit reverten. Es entspricht keiner gängigen Mappingpraxis (zumindest keiner die ich kenn) und bringt in den Daten genau keinen Mehrwert. Ich würd das einfach als Fehler ansehen und genauso behandeln. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
On Tue, 29 Jul 2014 00:37:53 +0200 eest9 eeston...@gmail.com wrote: Im Prinzip hast du Recht aber bitte nicht zu dem Nutzer selbst so garstig sein wenn man's ihm Erklärt da er sich laut Profil noch immer als Neuling fühlt ( http://www.openstreetmap.org/user/Railjet ). Wenn man ihm Erklärt warum das nicht sinnvoll ist usw. wird er es hoffentlich verstehen und in Zukunft diese Fehler nicht mehr machen. Na das wäre mal was Neues... sein track record sagt nämlich was ganz anderes. Es sieht eher so aus, als hätte er alle Schienen in Wien fertig gemappt und suche sich nun ein anderes Opfer... :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehweg-Flächen Kärntner Straße / Schwarzenbergplatz (Wien)
Hallo! da ist gerade ein eigenartiges Mapping der Gehwege als Flächen [...] Das ist unüblich, bringt nix und sieht ... aus. Bitte reverten. BTW, für so ich muß unbedingt Verkehrsflächen mappen-Anwandlungen empfehle ich http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway Das hier scheint das Changeset zu sein: http://www.openstreetmap.org/changeset/22826275 Ach Gott, dem Railjet ist wieder fad in der Birne... :( /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-lv] rigis miris ?
Nu atbilde skan kaut kā šādi: Kā man atbildēja - Linux pārlūkus RD neatbalsta! Bet reāli ir tā, ka uz vecākām pārlūku versijām RIGIS darbojas – iesakām Explorer 8 vai 9. Citiem pārlūkiem iespējams darbojas, bet ar dīvainībām – kā tavā gadījumā. Situācija ir tāda, ka veco RIGIS vairs augšā necels, bet ja kaut kas vispār būs, tad būs kaut kas jauns:) Cik atceros kaut kādā režijmā uz FF gāja, bet tas laikam ir atšāvies. Atradu vecu IE8 - maģija, tiešām strādā ;) On 26 July 2014 13:22, Rich ric...@nakts.net wrote: http://rigis.lv/ Active Server Pages error 'ASP 0113' Script timed out /map.asp The maximum amount of time for a script to execute was exceeded. You can change this limit by specifying a new value for the property Server.ScriptTimeout or by changing the value in the IIS administration tools. kaa taa ? -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-ca] Coastline or not coastline
Bonjour, Depuis longtemps je n’ose plus toucher aux rives du St-Laurent ni des rivières des Prairies et des Milles-Iles autour de Laval/Montréal. Je ne possède pas bien les notions de Coastline et de Riverbank. Pour l’instant le rendu à l’est de Laval/Montréal joue au yoyo. Des jours on voit les cours d’eau et d’autres jours ils disparaissent. En ce moment les iles sont en bleu et le fleuve est transparent: http://www.openstreetmap.org/#map=13/45.6857/-73.5521 Je prends comme exemple le chemin 81549185 où les ajouts et retraits de natural=coastline se succèdent. Je le remarque aussi ailleurs. Il semblerait que ce soit des corrections faites par des contributeurs suivant une alerte de OSM Inspector qui défont ce qu’un contributeur local tente de corriger. Y a-t-il quelque chose à faire? Qui a raison? Claude ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Coastline or not coastline
Bonjour Claude, J'ai réussi à repérer les chemins qui forment le contour de la rivière et ne sont plus rendus. Je vois que l'usager dmgroom_ct a deux sessions d'édition où il indique réparer les coastline! Voir sessions d'édition https://www.openstreetmap.org/changeset/24398188 et https://www.openstreetmap.org/changeset/24398161 Les chemins concernés sont dans les deux cas * 294703369, v2 * 81549185, v16 Ce contributeur a enlevé l'attribut natural=coastline, ne conservant que l'attribut waterway=riverbank. Actuellement, nous ne voyons plus l'embouchure de la rivière des Prairies où elle joint la riviière des Milles-Iles pres du fleuve. Mais bientôt ce sera toute la rivière jusqu'à la 125 qui va disparaitre. Validator de JOSM rapporte également les erreurs liés aux coastline. Il m'indique que les chemins ne sont pas tous bien orientés. Pour les coastline, la terre doit toujours être a gauche. Je vais corriger et envoyer une note a ce contributeur. Et espérons que j'ai repéré tous les problèmes. Pierre De : Alouette955 alouette...@gmail.com À : talk-ca talk-ca@openstreetmap.org Envoyé le : Lundi 28 juillet 2014 15h13 Objet : [Talk-ca] Coastline or not coastline Bonjour, Depuis longtemps je n’ose plus toucher aux rives du St-Laurent ni des rivières des Prairies et des Milles-Iles autour de Laval/Montréal. Je ne possède pas bien les notions de Coastline et de Riverbank. Pour l’instant le rendu à l’est de Laval/Montréal joue au yoyo. Des jours on voit les cours d’eau et d’autres jours ils disparaissent. En ce moment les iles sont en bleu et le fleuve est transparent: http://www.openstreetmap.org/#map=13/45.6857/-73.5521 Je prends comme exemple le chemin 81549185 où les ajouts et retraits de natural=coastline se succèdent. Je le remarque aussi ailleurs. Il semblerait que ce soit des corrections faites par des contributeurs suivant une alerte de OSM Inspector qui défont ce qu’un contributeur local tente de corriger. Y a-t-il quelque chose à faire? Qui a raison? Claude ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Coastline or not coastline
Je suis bien d'accord que ces usagers (qui ne semblent pas savoir tout à fait comment corriger le problème) devraient arrêter pour l'instant. Ceci dit, le coastline doit effectivement être corrigé. Présentement, les grands lacs canadiens sont taggés avec natural = coastline, l'embouchure du St-Laurent jusqu'à quelque part entre montréal et Trois-Rivières l'est aussi. Par contre, de la moitié de l'île Jésus/Île de Montréal vers l'est, natural=coastline est absent. Les tags présentement sont consistent (les coastlines sont fermées), mais le Canada a un coastline intérieur qui n'est pas connecté avec le coastline évident. Selon moi, il faudrait rajouter natural=coastline dans la section manquante pour reconnecter les grands lacs avec l'extérieur du continent. Il y a un autre cas de grands lacs taggés avec natural=coastline, il me semble en Afrique. La situation est problématique vu le grand nombre d'îles dans cette partie du St-Laurent. Je m'y suis attaqué moi aussi, mais je n'en savais pas assez pour terminer la correction. (Par contre, j'en savais assez pour abandonner mon changeset avant de causer un problème.) Je ne sais pas s'il y a un moyen de régler le problème à plusieurs. Seul, ça allait me prendre des semaines et je ne voulais pas créer des problèmes dans la base de données sur une si longue période. Si on se rencontrait tous dans un lieu commun avec un bon accès à internet (ou sur un serveur mumble, etc, etc), on pourrait peut-être diviser le travail en lot et le finir en un après-midi. Il y aurait plusieurs changesets, mais comme les niveaux de zoom moins élevés sont générés infréquemment, on pourrait passer entre 2 updates. Cheers, Charles On 14-07-28 05:10 PM, Pierre Béland wrote: Pierre Les usagers Rub21 et dmgroom_ct devraient cesser d'éditer le coastline au nord-est de lIle de montreal. Ils ne semblent pas connaitre les coastline. Users Rub21 and dmgroom_ct should stop editing coastline north-east of montreal island. They dont seem to know about coastlines. Je n'ai pas eu le temps d'examiner tous les edits usager Rub21. Il vient d'effacer puis recréer chemin. Il indique fixing lake. Et plusieurs autres edit avec même sujet http://www.openstreetmap.org/changeset/24410242 http://www.openstreetmap.org/user/Rub21 http://www.openstreetmap.org/changeset/24410148 http://www.openstreetmap.org/changeset/24410098 http://www.openstreetmap.org/changeset/24409680 svp cessez d'empirer la situation avec le coastline riviere des Prairies au nord-est de l'ile de Montreal. Bon, il faut envisager de revenir en arriere avec tous ces edit, de faire un Revert. Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Mapillary coverage in Vancouver
For some time I have been taking pictures to map from, and now that Mapillary is out, I finally have a way to share them. Mapillary is a company that is making a service similar to the old OpenStreetView, where they collect pictures of roads. The difference is that they currently offer the pictures under an open license, CC BY-SA, and they have given explicit permission to derive information for OpenStreetMap. They have a clever app, but what matters for me is that I can upload the pictures from my car-mounted camera after geotagging them. As I drive a reasonable distance and I've designed my setup for capturing images for mapping from, this means that the Mapillary coverage is building up in Greater Vancouver with excellent images for OSM use. The only problem is I have been unable to keep up with the rate I've been taking pictures. This means there's a lot of information in Mapillary pictures that can be entered into OSM. You can see the coverage at http://www.mapillary.com/map/im/12/49.2076/-122.8266. Note: The long straight lines are a bug in the Mapillary display. Because I have the raw images and GPX files, I haven't bothered to figure out a good workflow for using the Mapillary images in JOSM, and end up having a browser window open on one screen and JOSM on the other if I do need to use images from someone else. So, when mapping in Vancouver, consider Mapillary as a source. Technical: Images are captured at a settable interval, generally 2 seconds from a dash-mounted camera. Post-processing is then done for sharpness and contrast, time corrections applied, and the results correlated with GPX files from my GPS unit. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Coastline or not coastline
J'avais deja passé passablement de temps l'an dernier pour corriger a couvrir toute la zone jusqu'au lac St-Pierre. A partir des relations, Overpass pourrait sûrement nous aider a identifier / télécharger rapidement tous les chemins concernés. Puis je pense que le mieux est de placer l'attribut natural=coastline dans les relations. De cette façon, il y a moins de risque que des usagers inexpérimentés viennent modifier l'attribut. Pierre De : Charles Basenga Kiyanda perso...@charleskiyanda.com À : talk-ca@openstreetmap.org Envoyé le : Lundi 28 juillet 2014 23h40 Objet : Re: [Talk-ca] Coastline or not coastline Je suis bien d'accord que ces usagers (qui ne semblent pas savoir tout à fait comment corriger le problème) devraient arrêter pour l'instant. Ceci dit, le coastline doit effectivement être corrigé. Présentement, les grands lacs canadiens sont taggés avec natural = coastline, l'embouchure du St-Laurent jusqu'à quelque part entre montréal et Trois-Rivières l'est aussi. Par contre, de la moitié de l'île Jésus/Île de Montréal vers l'est, natural=coastline est absent. Les tags présentement sont consistent (les coastlines sont fermées), mais le Canada a un coastline intérieur qui n'est pas connecté avec le coastline évident. Selon moi, il faudrait rajouter natural=coastline dans la section manquante pour reconnecter les grands lacs avec l'extérieur du continent. Il y a un autre cas de grands lacs taggés avec natural=coastline, il me semble en Afrique. La situation est problématique vu le grand nombre d'îles dans cette partie du St-Laurent. Je m'y suis attaqué moi aussi, mais je n'en savais pas assez pour terminer la correction. (Par contre, j'en savais assez pour abandonner mon changeset avant de causer un problème.) Je ne sais pas s'il y a un moyen de régler le problème à plusieurs. Seul, ça allait me prendre des semaines et je ne voulais pas créer des problèmes dans la base de données sur une si longue période. Si on se rencontrait tous dans un lieu commun avec un bon accès à internet (ou sur un serveur mumble, etc, etc), on pourrait peut-être diviser le travail en lot et le finir en un après-midi. Il y aurait plusieurs changesets, mais comme les niveaux de zoom moins élevés sont générés infréquemment, on pourrait passer entre 2 updates. Cheers, Charles On 14-07-28 05:10 PM, Pierre Béland wrote: Pierre Les usagers Rub21 et dmgroom_ct devraient cesser d'éditer le coastline au nord-est de lIle de montreal. Ils ne semblent pas connaitre les coastline. Users Rub21 and dmgroom_ct should stop editing coastline north-east of montreal island. They dont seem to know about coastlines. Je n'ai pas eu le temps d'examiner tous les edits usager Rub21. Il vient d'effacer puis recréer chemin. Il indique fixing lake. Et plusieurs autres edit avec même sujet http://www.openstreetmap.org/changeset/24410242 http://www.openstreetmap.org/user/Rub21 http://www.openstreetmap.org/changeset/24410148 http://www.openstreetmap.org/changeset/24410098 http://www.openstreetmap.org/changeset/24409680 svp cessez d'empirer la situation avec le coastline riviere des Prairies au nord-est de l'ile de Montreal. Bon, il faut envisager de revenir en arriere avec tous ces edit, de faire un Revert. Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Výšky budov
Cus, kompletne spatne bych se psat neodvazoval, nebot podobne zmapovanych budov budou prinejmensim stovky. Ta stranka na wiki existuje rok, 3D budovy se vyrabej minimalne 3+ roky. A k rozmerum, pokud me skleroza neklame, tak se do rozmeru daj dat stopy, coz je v nasich koncinach sice nepravdepodobny, ale ... ;D Dne 27.7.2014 15:13, Michal Pustějovský napsal(a): Vypadá to, že se někdo (dle historie fotrous) pokoušel o 3D mapování, ale má to kompletně špatně. Části budov se nemají tagovat jako další budovy, ale správný postup je pomocí použití building:parts a relace building, více v EN zde: http://wiki.openstreetmap.org/wiki/Simple_3D_buildings . Příkladů v ČR se pár najde: OC Forum Nová Karolina Ostrava http://www.openstreetmap.org/relation/3883051 http://www.openstreetmap.org/relation/3883051#map=18/49.83241/18.28805 a http://www.openstreetmap.org/relation/3883049 (vizualizace http://demo.f4map.com/#lat=49.8309403lon=18.2867527zoom=18). Technologický park v Brně http://demo.f4map.com/#lat=49.2253533lon=16.5758574zoom=18camera.theta=69.637camera.phi=93.679 Layer se používá pouze pro 2D rendering. -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 7. 2014 11:43:19 Předmět: Re: [Talk-cz] Výšky budov ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Výšky budov
zdar, Netuším, jestli někdo na základě počtu pater zkouší odhadnout výšku budovy, ale bude to jen hodně, hodně přibližné. Osobně bych to nedělal. tak naokraj, to jsi vzal kde, že to bude hodně hodně přibližné? pokud jde o paneláky, ty mají shodnou výšku podlaží 2,8 m, viz https://cs.wikipedia.org/wiki/Panelový_dům#Typy_panelov.C3.BDch_dom.C5.AF_b.C4.9B.C5.BEn.C3.A9_v_.C4.8CR pro běžný dvanáctipatrák (13 podlaží) to dává 36,4 m, přízemí bývá metr zvednuté plus-mínus půl metru, střechu bych počítal čtyřicet plusmínus dvacet centimetrů takže jsme celkem na 37,8 m plusmínus 70 cm - čili asi plusmínus 2%, to snad není špatná přesnost ...? (navíc když to někdo někde zná, tak ví, jestli k tomu přízemí vedou dva schody nebo deset, čímž tu největší chybu eliminuje) K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Výšky budov
Tohle právě vedlo ke vzniku té 3D wiki stránky, protože mapovat jednu budovu pomocí X různých jen kvůli změně výšky apod. je nejen nepraktické (adresy, POI, vyhledávání...), ale také v rozporu s nepsanou zásadou Jeden reálný objekt, jeden objekt v OSM. -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 28. 7. 2014 10:22:54 Předmět: Re: [Talk-cz] Výšky budov Cus, kompletne spatne bych se psat neodvazoval, nebot podobne zmapovanych budov budou prinejmensim stovky. Ta stranka na wiki existuje rok, 3D budovy se vyrabej minimalne 3+ roky. A k rozmerum, pokud me skleroza neklame, tak se do rozmeru daj dat stopy, coz je v nasich koncinach sice nepravdepodobny, ale ... ;D Dne 27.7.2014 15:13, Michal Pustějovský napsal(a): Vypadá to, že se někdo (dle historie fotrous) pokoušel o 3D mapování, ale má to kompletně špatně. Části budov se nemají tagovat jako další budovy, ale správný postup je pomocí použití building:parts a relace building, více v EN zde: http://wiki.openstreetmap.org/wiki/Simple_3D_buildings . Příkladů v ČR se pár najde: OC Forum Nová Karolina Ostrava http://www.openstreetmap.org/relation/3883051 http://www.openstreetmap.org/relation/3883051#map=18/49.83241/18.28805 a http://www.openstreetmap.org/relation/3883049 (vizualizace http://demo.f4map.com/#lat=49.8309403lon=18.2867527zoom=18). Technologický park v Brně http://demo.f4map.com/#lat=49.2253533lon=16.5758574zoom=18camera.theta= 69.637camera.phi=93.679 Layer se používá pouze pro 2D rendering. -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 7. 2014 11:43:19 Předmět: Re: [Talk-cz] Výšky budov ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Deje se neco kolem TrackType?
Koukam, ze iDeditoru mi u cest prestal podsouvat pod nos k vyplneni atribut Tracktype (jak se tam nastavovala subjektivni kvalita cest Grade1-5). Najdu to jen v podrobnem vypisu vsech atributu. Tusite nekdo, proc tenhle atribut sebrali z predvoleb? Nedohodlo se nekde, ze se tenhle atribut uz nema pouzivat, nebo tak neco? Diky! -- Lukas Gebauer. http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib. http://geoget.ararat.cz/ - Geocaching solution ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Výšky budov
Dne 28.7.2014 11:57, Karel Volný napsal(a): zdar, Netuším, jestli někdo na základě počtu pater zkouší odhadnout výšku budovy, ale bude to jen hodně, hodně přibližné. Osobně bych to nedělal. tak naokraj, to jsi vzal kde, že to bude hodně hodně přibližné? pokud jde o paneláky, ty mají shodnou výšku podlaží 2,8 m, viz https://cs.wikipedia.org/wiki/Panelový_dům#Typy_panelov.C3.BDch_dom.C5.AF_b.C4.9B.C5.BEn.C3.A9_v_.C4.8CR pro běžný dvanáctipatrák (13 podlaží) to dává 36,4 m, přízemí bývá metr zvednuté plus-mínus půl metru, střechu bych počítal čtyřicet plusmínus dvacet centimetrů takže jsme celkem na 37,8 m plusmínus 70 cm - čili asi plusmínus 2%, to snad není špatná přesnost ...? (navíc když to někdo někde zná, tak ví, jestli k tomu přízemí vedou dva schody nebo deset, čímž tu největší chybu eliminuje) Ok. Beru zpět. Nevěděl jsem, že paneláky jsou až tak typizované ;-) Ale i tak ti zůstanou nejrůznější modely různých cihláků. Marián K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj, pár věcí:
* Opravil jsem skript, aby se díval i do pole KULTURA_KL, teď už taguje
zelinářskou zahradu atd.
* Když narazí na neznámý kód kultury, vyhodí výjmku místo tagu.
* Vyházel jsem zbývající ploty -- byly tam z nějakého důvodu?
* crop=vegetable nebo crop=vegetables ? taginfo zná víc těch prvních
* kul. 98 (rychle rostoucí dřeviny): landuse=scrub ???
* Proč se taguje id_fb? Je to k něčemu dobrý?
Zkoušel jsem nanečisto v JOSM napojování většího kusu dat na existující landuse
polygony, je to pěkná drbačka, překryvů a děr je víc než dost. Pokud Marián
dodělá tracer, který by přidával políčka jedno po druhým, byl by asi
praktičtější. (A pohrávám si s myšlenkou dodělat do JOSM funkci, která přilepí
úsek jedné cesty ke druhé mezi určenými body. Fakt nic takovýho neexistuje nebo
jen špatně hledám?)
Btw, rozjel jsem PostGIS a zkoušel totéž s parcelami RUIANu. Když se vhodně sloučí
parcely podle typů jak psal Petr Vejsada, tak je to taky použitelné. Proti LPISu RUIAN
líp pokrývá celou plochu KÚ, ale LPIS zase obecně víc odpovídá Bingu.
Problémů s napojováním na okolí je u obou zhruba stejně. (Docela pěkně vychází parcely
RUIANu ve městech a vesnicích. Zkusím z toho někdy zmapovat vnitřnosti u pár vesnic,
kolik klikací práce to ušetří.)
Martin
On 28.7.2014 14:53, Pavel Machek wrote:
Hi!
I'd like to start import of LPIS farmland database, as we have very
good coverage of houses, forests and water, but farmland is very good
at places and completely missing at different places.
Import page is at https://wiki.openstreetmap.org/wiki/LPIS , import
script will probably be ogr2osm + script below.
Best regards,
Pavel
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
def getKultura(attrs):
if 'KULTURA_KL' in attrs and attrs['KULTURA_KL'] != '':
return int(attrs['KULTURA_KL'])
if 'KULTURA' in attrs and attrs['KULTURA'] != '':
kul = int(attrs['KULTURA'])
return -1;
def filterTags(attrs):
if not attrs:
return
tags = {}
tags['source'] = 'lpis'
if 'ID_FB' in attrs:
tags['id_fb'] = attrs['ID_FB'];
if 'VYSKA' in attrs:
tags[ele] = %d % int(float(attrs['VYSKA']))
if 'NKODFB' in attrs:
tags[ref] = attrs['NKODFB']
kul = getKultura(attrs)
if kul == 2:tags[landuse] = farmland
elif kul == 3: tags[landuse] = farmland; tags[crop] = hop
elif kul == 30: tags[landuse] = farmland; tags[crop] = hop
elif kul == 31: tags[landuse] = farmland; tags[crop] = hop
elif kul == 41: tags[landuse] = vineyard
elif kul == 61: tags[landuse] = orchard
elif kul == 62: tags[landuse] = orchard
elif kul == 7: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 71: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 72: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 91: tags[landuse] = forest
elif kul == 92: tags[landuse] = farm; tags[crop] = vegetables
elif kul == 97: tags[landuse] = reservoir
elif kul == 98: tags[landuse] = scrub; tags[note]=rychle rostouci dreviny
elif kul == 99: tags[landuse] =forest
else: raise Exception (unknown farmland: %s % kul)
return tags
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj!
pro zajímavost, tvůj skript jsem při zkoumání LPISu nakonec zavrhl, jelikož
jsem našel tohle:
http://wiki.openstreetmap.org/wiki/Ogr2osm
Stačí doplnit translation funkci (vypůjčeno z pův. skriptu, v příloze) a
veškerou srandu udělá jeden příkaz:
ogr2osm.py PLPIS_233406_KU_KOD_742376.shp -t trn-lpis.py -o ujezd.lpis.osm
No, stahnul jsem si ogr2osm.py, ale nechce fungovat:
git clone git://github.com/pnorman/ogr2osm.git
pavel@amd:~/g/ogr2osm$ ./ogr2osm.py
File ./ogr2osm.py, line 538
featuresmap = {feature.geometry : feature for feature in
Feature.features}
^
SyntaxError: invalid syntax
pavel@amd:~/g/ogr2osm$ python3 ./ogr2osm.py
File ./ogr2osm.py, line 320
reproject = lambda(geometry): None
^
SyntaxError: invalid syntax
pavel@amd:~/g/ogr2osm$
To druhy jsem zvladnul nejak osalit, jenze nemam potrebny balicky pro python3:
from osgeo import ogr
from osgeo import osr
. Jestli ma nekdo napad...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On Mon 2014-07-28 22:35:11, Pavel Machek wrote:
Ahoj!
pro zajímavost, tvůj skript jsem při zkoumání LPISu nakonec zavrhl, jelikož
jsem našel tohle:
http://wiki.openstreetmap.org/wiki/Ogr2osm
Stačí doplnit translation funkci (vypůjčeno z pův. skriptu, v příloze) a
veškerou srandu udělá jeden příkaz:
ogr2osm.py PLPIS_233406_KU_KOD_742376.shp -t trn-lpis.py -o ujezd.lpis.osm
No, stahnul jsem si ogr2osm.py, ale nechce fungovat:
git clone git://github.com/pnorman/ogr2osm.git
pavel@amd:~/g/ogr2osm$ ./ogr2osm.py
File ./ogr2osm.py, line 538
featuresmap = {feature.geometry : feature for feature in
Feature.features}
^
SyntaxError: invalid syntax
pavel@amd:~/g/ogr2osm$ python3 ./ogr2osm.py
File ./ogr2osm.py, line 320
reproject = lambda(geometry): None
^
SyntaxError: invalid syntax
pavel@amd:~/g/ogr2osm$
To druhy jsem zvladnul nejak osalit, jenze nemam potrebny balicky pro
python3:
Tak vyreseno, ted by to melo bezet pod python 2.6 i 3+
Pavel
diff --git a/ogr2osm.py b/ogr2osm.py
index 587a5ae..0184262 100755
--- a/ogr2osm.py
+++ b/ogr2osm.py
@@ -317,13 +317,13 @@ def getTransform(layer):
# Some python magic: skip reprojection altogether by using a dummy
# lamdba funcion. Otherwise, the lambda will be a call to the OGR
# reprojection stuff.
-reproject = lambda(geometry): None
+reproject = lambda geometry: None
else:
destSpatialRef = osr.SpatialReference()
# Destionation projection will *always* be EPSG:4326, WGS84 lat-lon
destSpatialRef.ImportFromEPSG(4326)
coordTrans = osr.CoordinateTransformation(spatialRef, destSpatialRef)
-reproject = lambda(geometry): geometry.Transform(coordTrans)
+reproject = lambda geometry: geometry.Transform(coordTrans)
return reproject
@@ -535,7 +535,7 @@ def output():
nodes = [geom for geom in Geometry.geometries if type(geom) == Point]
ways = [geom for geom in Geometry.geometries if type(geom) == Way]
relations = [geom for geom in Geometry.geometries if type(geom) ==
Relation]
-featuresmap = {feature.geometry : feature for feature in Feature.features}
+featuresmap = dict([(feature.geometry, feature) for feature in
Feature.features])
# Open up the output file with the system default buffering
with open(options.outputFile, 'w', -1) as f:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On 28.7.2014 22:35, Pavel Machek wrote: To druhy jsem zvladnul nejak osalit, jenze nemam potrebny balicky pro python3: from osgeo import ogr from osgeo import osr . Jestli ma nekdo napad... Pavel Mně to fungovalo samo od sebe... Koukám do systému, ogr.py/osr.py mi do Gentoo zavlekla GDAL knihovna s python USE flagem. A jako aktivní python mám 2.7. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Dne 28.7.2014 21:39, Martin S(vec - OSM napsal(a): Ahoj, pár ve(cí: * Opravil jsem skript, aby se díval i do pole KULTURA_KL, ted( uz( taguje zelinár(skou zahradu atd. * Kdyz( narazí na neznámý kód kultury, vyhodí výjmku místo tagu. * Vyházel jsem zbývající ploty -- byly tam z ne(jakého du*vodu? * crop=vegetable nebo crop=vegetables ? taginfo zná víc te(ch prvních * kul. 98 (rychle rostoucí dr(eviny): landuse=scrub ??? * Proc( se taguje id_fb? Je to k ne(c(emu dobrý? Zkous(el jsem nanec(isto v JOSM napojování ve(ts(ího kusu dat na existující landuse polygony, je to pe(kná drbac(ka, pr(ekryvu* a de(r je víc nez( dost. Pokud Marián dode(lá tracer, který by pr(idával políc(ka jedno po druhým, byl by asi praktic(te(js(í. Dode(lám, dode(lám. Sám to uz( nutne( potr(ebuji ;-) Jen nevím kdy to bude. Momentálne( r(es(ím konflikty v poslední verzi Traceru a zatím se mi ne(jak nedar(í. Je tam ne(co s(patne(, ale ne a ne pr(ijít na to co :-( (A pohrávám si s mys(lenkou dode(lat do JOSM funkci, která pr(ilepí úsek jedné cesty ke druhé mezi urc(enými body. Fakt nic takovýho neexistuje nebo jen s(patne( hledám?) Moz(ná je trochu problém, jak poznat co se k c(emu má pr(ilepit, pr(ípadne( jak to jednodus(e zadat. Marián Btw, rozjel jsem PostGIS a zkous(el totéz( s parcelami RUIANu. Kdyz( se vhodne( slouc(í parcely podle typu* jak psal Petr Vejsada, tak je to taky pouz(itelné. Proti LPISu RUIAN líp pokrývá celou plochu KÚ, ale LPIS zase obecne( víc odpovídá Bingu. Problému* s napojováním na okolí je u obou zhruba stejne(. (Docela pe(kne( vychází parcely RUIANu ve me(stech a vesnicích. Zkusím z toho ne(kdy zmapovat vnitr(nosti u pár vesnic, kolik klikací práce to us(etr(í.) Martin On 28.7.2014 14:53, Pavel Machek wrote: Hi! I'd like to start import of LPIS farmland database, as we have very good coverage of houses, forests and water, but farmland is very good at places and completely missing at different places. Import page is at https://wiki.openstreetmap.org/wiki/LPIS , import script will probably be ogr2osm + script below. Best regards, Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj! * Opravil jsem skript, aby se díval i do pole KULTURA_KL, teď už taguje zelinářskou zahradu atd. * Když narazí na neznámý kód kultury, vyhodí výjmku místo tagu. * Vyházel jsem zbývající ploty -- byly tam z nějakého důvodu? No, pro me je informace o plotech docela dulezita.. mam pocit ze vinice a chmelnice plot proste maji. Ale asi je to trochu drze... * crop=vegetable nebo crop=vegetables ? taginfo zná víc těch prvních Tak vemem crop=vegerable... * kul. 98 (rychle rostoucí dřeviny): landuse=scrub ??? http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub Aha, ma tam byt natural, ale jinak to myslim sedi. Opravim. * Proč se taguje id_fb? Je to k něčemu dobrý? Asi neni. Vyhodim ho. Zkoušel jsem nanečisto v JOSM napojování většího kusu dat na existující landuse polygony, je to pěkná drbačka, překryvů a děr je víc než dost. Pokud Marián dodělá tracer, který by přidával políčka jedno po druhým, byl by asi praktičtější. No, ja bych uplne landuse=farmland napriklad s lesama nespojoval.. ono vedle toho lesa byva ruzne siroky pruh ne-lesa ale jeste taky ne-pole. (A pohrávám si s myšlenkou dodělat do JOSM funkci, která přilepí úsek jedné cesty ke druhé mezi určenými body. Fakt nic takovýho neexistuje nebo jen špatně hledám?) Nevim o ni. Btw, rozjel jsem PostGIS a zkoušel totéž s parcelami RUIANu. Když se vhodně sloučí parcely podle typů jak psal Petr Vejsada, tak je to taky použitelné. Proti LPISu RUIAN líp pokrývá celou plochu KÚ, ale LPIS zase obecně víc odpovídá Bingu. Problémů s napojováním na okolí je u obou zhruba stejně. (Docela pěkně vychází parcely RUIANu ve městech a vesnicích. Zkusím z toho někdy zmapovat vnitřnosti u pár vesnic, kolik klikací práce to ušetří.) No, kdyby z toho byly nejaky soubory, treba pro okoli rican, tak se na rad podivam. Kdyby se v osm objevily ploty, tak me to hodne potesi... a ploty by mely jit vykoukat z mistni znalosti + hranic pozemku. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On 28.7.2014 23:03, Pavel Machek wrote: No, pro me je informace o plotech docela dulezita.. mam pocit ze vinice a chmelnice plot proste maji. Ale asi je to trochu drze... Mně se nelíbily ploty kolem a napříč loukami, kde vím že tam určitě nejsou. U vinic+chmelnic... mno, tam je pravděpodobnost plotu asi docela vysoká. Těžko říct... http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub Aha, ma tam byt natural, ale jinak to myslim sedi. Opravim. Znova jsem se nad tím zamyslel... Záleží, co se myslí porostem rychle rostoucích dřevin. Natural=scrub je neobhospodařovaná příroda, landuse=* je obhospodařovaná krajina. Jestli jsou to plantáže na biomasu, landuse by tomu slušel víc. (Taginfo landuse=scrub zná, ale většinou na uzlech (wtf, jednotlivé keře?). Co jsem namátkou našel na polygonech, tak je to chybně otagovaný natural=scrub.) Update: jo, je to biomasa: viz par. 3i písm. j) zákona č. 252/1997 Sb. Zkoušel jsem nanečisto v JOSM napojování většího kusu dat na existující landuse polygony, je to pěkná drbačka, překryvů a děr je víc než dost. Pokud Marián dodělá tracer, který by přidával políčka jedno po druhým, byl by asi praktičtější. No, ja bych uplne landuse=farmland napriklad s lesama nespojoval.. ono vedle toho lesa byva ruzne siroky pruh ne-lesa ale jeste taky ne-pole. To je asi individuální... Když jsou mezi lesem a polem tři metry křovin a šouší, dávám pruh natural=scrub. Když jsou na okraji jen koleje od traktoru a rovnou les, spojuju přímo. Nemám rád v mapě bílé škvíry :-) Ty pruhy křoví jsou občas přímo v KM. Btw, rozjel jsem PostGIS a zkoušel totéž s parcelami RUIANu. Když se vhodně sloučí parcely podle typů jak psal Petr Vejsada, tak je to taky použitelné. Proti LPISu RUIAN líp pokrývá celou plochu KÚ, ale LPIS zase obecně víc odpovídá Bingu. Problémů s napojováním na okolí je u obou zhruba stejně. (Docela pěkně vychází parcely RUIANu ve městech a vesnicích. Zkusím z toho někdy zmapovat vnitřnosti u pár vesnic, kolik klikací práce to ušetří.) No, kdyby z toho byly nejaky soubory, treba pro okoli rican, tak se na rad podivam. Kdyby se v osm objevily ploty, tak me to hodne potesi... a ploty by mely jit vykoukat z mistni znalosti + hranic pozemku. Pokusím se vyrobit ukázku, až to trochu učešu. Ale teď se k tomu pár dnů nedostanu. Zatím hlavně googlím, co vůbec PostGIS nad daty dokáže. Btw, ty ploty... To je nějaká specifická úchylka? :-)) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] import lieux-dits (avec fixme)
Bonjour, Est-ce quelqu'un est au courant d'un import pour les lieux-dits avec ajout d'un fixme à vérifier: lieu créé automatiquement à partir des adresses du coin. Il me semblait qu'on ne devait pas créer des fixme de façon automatique. Et la mention adresses du coin me paraît étrange. Une nouvelle source ? Échantillon : http://keepright.ipax.at/report_map.php?zoom=13lat=46.5245lon=4.10807layers=B0Tch=0%2C170show_ign=0show_tmpign=0 Je ne sais pas quantifier le problème mais il y en a visiblement un très grand nombre. PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Bonjour, Le 28/07/2014 09:53, Pierre-Yves Berrard a écrit : Bonjour, Est-ce quelqu'un est au courant d'un import pour les lieux-dits avec ajout d'un fixme à vérifier: lieu créé automatiquement à partir des adresses du coin. C'est vrai que les imports fleurissent en ce moment... Avec des fautes d'orthographe non corrigées (accents notamment), et le pire, avec des tags place=neighbourhood en lieu et place de place=locality (voire hamlet ou isolated_dweeling dans certains cas). Les corrections à apporter sont innombrables, mais heureusement qu'il y a ce tag fixme, ça permet de les repérer plus facilement. Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
N'hésitez pas à contacter les contributeurs, c'est la première chose à faire... Le 28 juillet 2014 10:08, Samy Mezani samy.mez...@wanadoo.fr a écrit : Bonjour, Le 28/07/2014 09:53, Pierre-Yves Berrard a écrit : Bonjour, Est-ce quelqu'un est au courant d'un import pour les lieux-dits avec ajout d'un fixme à vérifier: lieu créé automatiquement à partir des adresses du coin. C'est vrai que les imports fleurissent en ce moment... Avec des fautes d'orthographe non corrigées (accents notamment), et le pire, avec des tags place=neighbourhood en lieu et place de place=locality (voire hamlet ou isolated_dweeling dans certains cas). Les corrections à apporter sont innombrables, mais heureusement qu'il y a ce tag fixme, ça permet de les repérer plus facilement. Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Bonjour, Cela répond partiellement à mon premier message posté il y a quelques jours (Lieux-dits dans la lignée du projet BANO). Donc l'import automatique est réalisable. - J'ai pu noter des différences avec Des lieux-dits déjà présent dans la base (exemple En Vesvre dans la base, et avec l'import cela devient En Vèvre ou encore Le bois Plain devient Le Bois Plein avec l'import). - Il manque également les indications de type de lieux dit effectivement. Cette information est dans le fichier Fantoir. Est-il possible d'exploiter cette information avant de réaliser un import ? Pour appliquer les bon tags place (Hamlet, locality) ? Merci par avance pour vos réponses. Eric -- View this message in context: http://gis.19327.n5.nabble.com/import-lieux-dits-avec-fixme-tp5812867p5812878.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
2014-07-28 11:04 GMT+02:00 tadj epe...@yahoo.fr: - J'ai pu noter des différences avec Des lieux-dits déjà présent dans la base (exemple En Vesvre dans la base, et avec l'import cela devient En Vèvre ou encore Le bois Plain devient Le Bois Plein avec l'import). Il faut regarder au cas par cas. La différence peut venir d'une erreur de saisie ou de l'utilisation d'une source obsolète (je pense à Vesvre au lieu de Vèvre qui ressemble à du vieux français). On ne peut aussi pas exclure que certains contributeurs confondent leurs souhaits personnels avec la réalité. - Il manque également les indications de type de lieux dit effectivement. Cette information est dans le fichier Fantoir. Est-il possible d'exploiter cette information avant de réaliser un import ? Pour appliquer les bon tags place (Hamlet, locality) ? Quelle est la définition de type de lieux dans le Fantoir ? Il faut voir si c'est transposable pour certaines valeurs. Le faire automatiquement est encore une autre histoire (vérifier avec l'existant, toponymie changeante (cadastre), etc). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Autre question que je me pose : quelle est la vérifiabilité de ces toponymes sur le terrain ? Et par conséquent est-il souhaitable de tous les ajouter dans osm ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Pour beaucoup de noms de lieux-dits, la vérifiabilité est souvent orale ;) Il y a des panneaux pour les hameaux, les écarts (et encore), mais pour les lieux-dits c'est exceptionnel alors qu'ils existent bien quand on interroge les locaux (agés). Le 28 juillet 2014 11:21, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Autre question que je me pose : quelle est la vérifiabilité de ces toponymes sur le terrain ? Et par conséquent est-il souhaitable de tous les ajouter dans osm ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
2014-07-28 11:21 GMT+02:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Autre question que je me pose : quelle est la vérifiabilité de ces toponymes sur le terrain ? Et par conséquent est-il souhaitable de tous les ajouter dans osm ? Euh, l'immense majorité des lieux-dits ne sont pas indiqués par un panneau sur place ;-) La seule vérifiabilité serait peut-être du côté des propriétaires des terrains, ceux qui s'en servent et/ou des vieux du village. De nombreux noms tirés du cadastre sont anciens et suivant les endroits, peuvent parfois tomber en désuettude (après remembrements par ex,). Pour ceux-là, on peut effectivement se poser la question de les garder ou pas dans OSM (mais c'est une questions que seuls les locaux peuvent répondre). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28/07/2014 11:32, Christian Quest a écrit : ils existent bien quand on interroge les locaux (agés) Quand ils sont tous d'accord entre eux... ;-) Et les patois locaux ont pu déformer les noms. La seule source fiable reste désormais le cadastre à mon avis... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
On dit aussi que le terrain prime, mais quel terrain ? Je connais un lieu-dit pour lequel la poste, le cadastre et les habitants utilsent une orthographe avec la lettre O... alors que le panneau local utilse AU Art. Le 28 juillet 2014 11:39, Pieren pier...@gmail.com a écrit : 2014-07-28 11:21 GMT+02:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Autre question que je me pose : quelle est la vérifiabilité de ces toponymes sur le terrain ? Et par conséquent est-il souhaitable de tous les ajouter dans osm ? Euh, l'immense majorité des lieux-dits ne sont pas indiqués par un panneau sur place ;-) La seule vérifiabilité serait peut-être du côté des propriétaires des terrains, ceux qui s'en servent et/ou des vieux du village. De nombreux noms tirés du cadastre sont anciens et suivant les endroits, peuvent parfois tomber en désuettude (après remembrements par ex,). Pour ceux-là, on peut effectivement se poser la question de les garder ou pas dans OSM (mais c'est une questions que seuls les locaux peuvent répondre). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] effacement volontaire de radar
Hello, Merci mais ce que j'ai supposé comprendre c'est de joindre des parties de routes pour dire que sur X metres il y a possibilité de se prendre une prune... je voudrais bien essayer de le faire moi-meme ces enforcements -- View this message in context: http://gis.19327.n5.nabble.com/effacement-volontaire-de-radar-tp5812599p5812892.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Je ne sais pas quantifier le problème mais il y en a visiblement un très grand nombre. Plus de 57 000, en fait. Mon souci majeur, c'est l'utilisation du fixme (qui va cacher les autres fixme ajoutés à la main). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] effacement volontaire de radar
Bonjour Le 28/07/2014 11:48, willemijns a écrit : routes pour dire que sur X metres il y a possibilité de se prendre une prune... On cartographie l'existence sur le terrain. Le radar : « il est là », et non pas : « faite gaffe entre là et là, y'a un radar » Et définir un radar, c'est une relation comportant 3 informations : - L'emplacement physique du phototachygraphe (noeud) (non obligatoirement sur une chemin de type « highway » - Les emplacements, situé sur le chemin de type « highway » concerné définissant via le rôle « from » et « to » le sens de circulation pour lequel le phototachygraphe peut émettre un avis d'information à l'attention d'un propriétaire d'un véhicule. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Quelle est la définition de type de lieux dans le Fantoir ? Il faut voir si c'est transposable pour certaines valeurs. Le faire automatiquement est encore une autre histoire (vérifier avec l'existant, toponymie changeante (cadastre), etc). Dans Fantoir colonne 110 sur 1 caractère on trouve l'information. 1 = Lieu-dit Bâti et 0 non Bâti. Eric -- View this message in context: http://gis.19327.n5.nabble.com/import-lieux-dits-avec-fixme-tp5812867p5812901.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
2014-07-28 12:43 GMT+02:00 tadj epe...@yahoo.fr: Dans Fantoir colonne 110 sur 1 caractère on trouve l'information. 1 = Lieu-dit Bâti et 0 non Bâti. J'ai cru comprendre lors de précédentes discussions que ce flag n'était pas très fiable... Sinon, une seule valeur serait transposable (non bâti= place=locality) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
2014-07-28 11:58 GMT+02:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Plus de 57 000, en fait. Mon souci majeur, c'est l'utilisation du fixme (qui va cacher les autres fixme ajoutés à la main). 57000, ça fait beaucoup. Surtout que sur les 2,3 que j'ai regardé, il y a place=neighbourhood, ce qui est un usage incorrect en rase campagne (locality ou isolated_dweeling ou hamlet serait plus approprié) Est-ce que c'est 57.000 du même auteur ? Il faut lui demander de suspendre son import et en rediscuter. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28 juillet 2014 09:53, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Est-ce quelqu'un est au courant d'un import pour les lieux-dits avec ajout d'un fixme à vérifier: lieu créé automatiquement à partir des adresses du coin. Il me semblait qu'on ne devait pas créer des fixme de façon automatique. Et la mention adresses du coin me paraît étrange. Une nouvelle source ? Les données sont extraites automatiquement depuis les adresses des parcelles du cadastre et disponibles ici http://cadastre.openstreetmap.fr/ Le point est positionné au barycentre des adresses sans numéro. Il y aurais certainement moyen d'affiner le résultat en analysant les buildings présent dans les parcelles mais si les adresses des parcelles ayant une maison ont un numéro elle ne seront pas prises en compte donc ça restera imprécis. La qualité peut varier d'une commune à l'autre, c'est pourquoi j'ai laissé un fixme, mais on peut au choix: - ne plus mettre de fixme - ne plus rendre ces données disponibles (comme pour l'eau) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] effacement volontaire de radar
Le 28/07/2014 12:11, David Crochet a écrit : Bonjour Le 28/07/2014 11:48, willemijns a écrit : routes pour dire que sur X metres il y a possibilité de se prendre une prune... On cartographie l'existence sur le terrain. Le radar : « il est là », et non pas : « faite gaffe entre là et là, y'a un radar » Et définir un radar, c'est une relation comportant 3 informations : - L'emplacement physique du phototachygraphe (noeud) (non obligatoirement sur une chemin de type « highway » - Les emplacements, situé sur le chemin de type « highway » concerné définissant via le rôle « from » et « to » le sens de circulation pour lequel le phototachygraphe peut émettre un avis d'information à l'attention d'un propriétaire d'un véhicule. Et on essaye de séparer les nœuds from et device de quelques centaines de mètres afin de bien marquer la zone de danger et permettre aux automobilistes d'anticiper et adapter leur conduite au danger. Sauvons des vies ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] effacement volontaire de radar
je ne suis pas complètement en phase avec ce dernier message, le mappeur doit donner la direction, le nombre de mètres avant se fait en fonction de l'outil utilisé, inutile de s'embêter à avoir à parcourir plusieurs centaines de mètres pour modifier les données. -- Jean-Baptiste Holcroft Le 28 juillet 2014 13:13, Christophe Merlet red...@redfoxcenter.org a écrit : Le 28/07/2014 12:11, David Crochet a écrit : Bonjour Le 28/07/2014 11:48, willemijns a écrit : routes pour dire que sur X metres il y a possibilité de se prendre une prune... On cartographie l'existence sur le terrain. Le radar : « il est là », et non pas : « faite gaffe entre là et là, y'a un radar » Et définir un radar, c'est une relation comportant 3 informations : - L'emplacement physique du phototachygraphe (noeud) (non obligatoirement sur une chemin de type « highway » - Les emplacements, situé sur le chemin de type « highway » concerné définissant via le rôle « from » et « to » le sens de circulation pour lequel le phototachygraphe peut émettre un avis d'information à l'attention d'un propriétaire d'un véhicule. Et on essaye de séparer les nœuds from et device de quelques centaines de mètres afin de bien marquer la zone de danger et permettre aux automobilistes d'anticiper et adapter leur conduite au danger. Sauvons des vies ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28 juillet 2014 13:07, Pieren pier...@gmail.com a écrit : il y a place=neighbourhood, ce qui est un usage incorrect en rase campagne (locality ou isolated_dweeling ou hamlet serait plus approprié) Dans ma campagne les maisons sont le plus souvent isolées et on parle de quartier et non pas de lieu-dit. Il y a en général de 2 à 10 maisons dans le même quartiers, mais elles sont loin les unes des autres, j'ai jamais trouvé quel tag place= j'étais sensé utiliser. Ça ne peut pas être des isolated_dwelling avec plus de 2 maisons et ce n'est certainement pas des hameaux. La définition du wiki pour place=neighbourhood [1] ne mentionne pas le fait que ça doit être en zone urbaine et la description qui est faite correspond tout à fait là définition que je donne des quartiers de ma rase campagne (cad banlieu d'un village...) [1] http://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dneighbourhood ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28 juillet 2014 13:47, Tyndare tynd...@wanadoo.fr a écrit : Dans ma campagne les maisons sont le plus souvent isolées et on parle de quartier et non pas de lieu-dit. Il y a en général de 2 à 10 maisons dans le même quartiers, mais elles sont loin les unes des autres, j'ai jamais trouvé quel tag place= j'étais sensé utiliser. Ça ne peut pas être des isolated_dwelling avec plus de 2 maisons et ce n'est certainement pas des hameaux. La définition du wiki pour place=neighbourhood [1] ne mentionne pas le fait que ça doit être en zone urbaine et la description qui est faite correspond tout à fait là définition que je donne des quartiers de ma rase campagne (cad banlieu d'un village...) Le wiki précise que neighbourhood est une aire géographique localisée au sein d'un plus grand ensemble. Cette définition ne correspond pas à des groupes de maison en campagne. On parle plutôt dans ce cas de hameau soit place=hamlet. Pourquoi dis-tu que hameau ne conviendrait pas? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28/07/2014 13:47, Tyndare a écrit : Le 28 juillet 2014 13:07, Pieren pier...@gmail.com a écrit : il y a place=neighbourhood, ce qui est un usage incorrect en rase campagne (locality ou isolated_dweeling ou hamlet serait plus approprié) Dans ma campagne les maisons sont le plus souvent isolées et on parle de quartier et non pas de lieu-dit. Il y a en général de 2 à 10 maisons dans le même quartiers, mais elles sont loin les unes des autres, j'ai jamais trouvé quel tag place= j'étais sensé utiliser. Ça ne peut pas être des isolated_dwelling avec plus de 2 maisons et ce n'est certainement pas des hameaux. La définition du wiki pour place=neighbourhood [1] ne mentionne pas le fait que ça doit être en zone urbaine et la description qui est faite correspond tout à fait là définition que je donne des quartiers de ma rase campagne (cad banlieu d'un village...) [1] http://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dneighbourhood Je suis de l'avis de Pieren. Dans le même esprit, ce n'est pas parce que tes habitants de quartiers disent qu'ils vont à la ville pour acheter le pain, que ton place=village doit devenir un place=city ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
2014-07-28 13:58 GMT+02:00 Romain MEHUT romain.me...@gmail.com: Le wiki précise que neighbourhood est une aire géographique localisée au sein d'un plus grand ensemble. Cette définition ne correspond pas à des groupes de maison en campagne. On parle plutôt dans ce cas de hameau soit place=hamlet. Pourquoi dis-tu que hameau ne conviendrait pas? La traduction de neighbourhood par quartier est sans doute la plus appropriée. Mais ce terme ne s'applique pas à des groupes d'habitations isolées ni a des lieux-dits sans bâti comme j'ai pu le voir dans la zone mentionnée au début de ce fil. Pour des zones résidentielles dispersées, je n'ai pas de problème à priori à l'utilisation de neighbourhood. Il y a une zone grise entre habitats dispersés et isolés. Tout dépend de la topologie et des distances (dispersées façon puzzle ou comme des grappes de raisins) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
2014-07-28 13:10 GMT+02:00 Tyndare tynd...@wanadoo.fr: Les données sont extraites automatiquement depuis les adresses des parcelles du cadastre et disponibles ici http://cadastre.openstreetmap.fr/ En effet, je constate que l'outil d'extraction des adresses crée un tas the place=neighbourhood (comme on le voit en [1]). Je ne me souviens pas qu'une telle décision ait été prise au niveau du groupe. La plupart des lieux-dits sont inhabités ou isolés en campagne. Le tag place=neighbourhood est donc faux dans 99% des cas. Malheureusement, on constate maintenant leur prolifération dans la base de donnée avec des tonnes de fixme que personne ne prend le temps de fixer. Il faut mettre le hola à cette vague de données incontrollées (déjà 57.000 d'après certains en fixme, qui s'en charge ?). Pieren [1] http://cadastre.openstreetmap.fr/data/071/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osm : entre 2007 et maintenant
Bonjour, Je ne sais pas si vous avez vu ce lien (je n'ai rien vu circuler ici à ce sujet...) : http://mvexel.github.io/thenandnow/ Ce site Web montre l'évolution d'OpenStreetMap, entre 2007 et maintenant (je suppose cependant que la feuille de rendu Mapnik utilisée des 2 cotés et la même : l'actuelle). J'avoue que ça flatte bien l'ego que voir tout le travail parcouru en 7 ans, et se dire qu'on y a apporté une (plus ou moins) modeste pierre... Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le wiki précise que neighbourhood est une aire géographique localisée au sein d'un plus grand ensemble. Cette définition ne correspond pas à des groupes de maison en campagne. On parle plutôt dans ce cas de hameau soit place=hamlet. Pourquoi dis-tu que hameau ne conviendrait pas? J'ai certainement un problème de compréhension de la définition du tag place, mais pour moi des maisons isolées ça ne s'appelle pas un hameau, un hameau c'est quand elles sont regroupées. Je parle de maisons isolées mais qui ont la même adresse (le même nom de quartier). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm : entre 2007 et maintenant
Impressionnant Le 28 juillet 2014 14:25, Francescu GAROBY f.gar...@gmail.com a écrit : Bonjour, Je ne sais pas si vous avez vu ce lien (je n'ai rien vu circuler ici à ce sujet...) : http://mvexel.github.io/thenandnow/ Ce site Web montre l'évolution d'OpenStreetMap, entre 2007 et maintenant (je suppose cependant que la feuille de rendu Mapnik utilisée des 2 cotés et la même : l'actuelle). J'avoue que ça flatte bien l'ego que voir tout le travail parcouru en 7 ans, et se dire qu'on y a apporté une (plus ou moins) modeste pierre... Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28 juillet 2014 14:27, Tyndare tynd...@wanadoo.fr a écrit : J'ai certainement un problème de compréhension de la définition du tag place, mais pour moi des maisons isolées ça ne s'appelle pas un hameau, un hameau c'est quand elles sont regroupées. Je parle de maisons isolées mais qui ont la même adresse (le même nom de quartier). Reste à savoir où tu mets la distinction entre regroupées et isolées? Tu peux donner un lien vers un exemple d'endroit? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import lieux-dits (avec fixme)
Le 28 juillet 2014 14:32, Romain MEHUT romain.me...@gmail.com a écrit : Le 28 juillet 2014 14:27, Tyndare tynd...@wanadoo.fr a écrit : J'ai certainement un problème de compréhension de la définition du tag place, mais pour moi des maisons isolées ça ne s'appelle pas un hameau, un hameau c'est quand elles sont regroupées. Je parle de maisons isolées mais qui ont la même adresse (le même nom de quartier). Reste à savoir où tu mets la distinction entre regroupées et isolées? Tu peux donner un lien vers un exemple d'endroit? Je vais me faire taper sur les doigts, mais tant pis je l'ai mérité, voici une limite d'un quartier d'après le cadastre: http://www.openstreetmap.org/relation/3768032 à priori il y a 3 fermes qui ont cette adresse là mais il faut faire pas mal de route pour aller de l'une à l'autre. Ça devrais être place=hamlet ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
Un peu plus de 1300 noeuds concernés ajoutés par une demie-douzaine de contributeurs... que je vais contacter de ce pas. Ca ne sert à rien de se lamenter ici sans le signaler directement aux quelques intéressés. Si besoin, il faudra aussi rectifier le script d'extraction pour ne pas mettre de place=* et donc forcer les contributeurs à les ajouter avant upload. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm : entre 2007 et maintenant
Impressionnant en effet. Quand je vois ça je me demande comment les tarés que nous sommes ont pu un instant croire que ça pouvait marcher ! Il y avait pourtant de quoi être largement découragé par l'ampleur de la tâche. Et pourtant quand on voit la quantité de détails 7 ans plus tard hé ben ça marche même très bien. En ce qui me concerne je ne suis arrivé dans la partie que fin 2009 et j'aimerai bien voir la tête qu'avait la carte à ce moment là. Merci Francescu pour le lien. Nicolas - Nicolas Moyroud Site web libre@vous : http://libreavous.teledetection.fr - Le 28/07/2014 14:30, Ab_fab a écrit : Impressionnant Le 28 juillet 2014 14:25, Francescu GAROBY f.gar...@gmail.com mailto:f.gar...@gmail.com a écrit : Bonjour, Je ne sais pas si vous avez vu ce lien (je n'ai rien vu circuler ici à ce sujet...) : http://mvexel.github.io/thenandnow/ Ce site Web montre l'évolution d'OpenStreetMap, entre 2007 et maintenant (je suppose cependant que la feuille de rendu Mapnik utilisée des 2 cotés et la même : l'actuelle). J'avoue que ça flatte bien l'ego que voir tout le travail parcouru en 7 ans, et se dire qu'on y a apporté une (plus ou moins) modeste pierre... Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
