La Yuca Amarga Es Un Tubérculo Que Aparentemente Puede Parecerse A La Yuca Normal, Pero En Realidad Su Base Está Compuesta Por Cianuro O Ácido Cianhídrico.

Si La Yuca Amarga No Es Cocinada O Tratada De Forma Adecuada, Puede Causar Una Intoxicación Tan Severa Que Puede Ocasionar El Fallo Masivo De Los Órganos Vitales Del Cuerpo Humano, Como El Hígado O El Cerebro Mismo.

La Yuca Amarga Contiene 0,01 Miligramos De Cianuro O Ácido Cianhídrico Por Cada Gramo De Yuca Lo Que Es Totalmente Toxico.

No Es Posible Diferenciar La Yuca Amarga y Yuca Dulce Por Su Apariencia. Una De Las Pruebas Más Efectivas Para Saber Si Una Yuca Es Amarga O No, Es Colocando La Lengua En El Centro De La Raíz De La Yuca. Si La Lengua Se Adormece O Se Percibe Algún Sabor Amargo, Esto Indica Que Esa Yuca Tiene Un Alto Contenido De Cianuro.

Hallo ihr Lieben,

da ich selber ein begeisterter Outdoor Fan bin, habe ich eine Website erstellt, wo man sich seine individuellen Landkarten online erstellen kann und diese dann ausgedruckt nach Hause bekommt. Ich fand es persönlich hilfreich grade auf längeren Trekking Touren, eine Papierkarte dabei zu haben und mich nicht ausschließlich auf die moderne Technik zu verlassen. Außerdem konnte ich auf der Papierkarte meine Route besser planen. Ich würde mich super über euer Feedback zu der Website (https://printmymap.world/de/) freuen. Bin noch nicht ganz happy damit. Ich freue mich über Feedback. Viele Grüße aus der Schweiz

深秋真是阴冷，寒风阵阵耸耸，唯有甜沫香浓。

Fortunately I am typically editing area that is not a victim of landuse imports.

Unfortunately today I am trying to fix area affected by at least two landuse imports

As bonus, one is using mysterious undocumented CLC:code, CLC:shapeId tags that are not documented anywhere and it is not clear what one should do with them on modifying and merging areas with them.

Is there anywhere at least one large-scale import of landuse data that was done properly?

Our Zen Center hold a regular outreach progam for kids called Bodhi Star. Along with teaching basic mindfulness techniques, life-skill ideas and concepts are also taught or introduced.

Yesterday, it was my turn to teach skills class and I've always been keen on teaching something related to maps and geography.

The kids had great fun trying to identify objects from aerial imagery, "visiting" remote places, and wonder about the beauty of our vast, interconnected world.

Some of the places we visited had limited street-level imagery, which they were quite fond of, so I even got to discuss Mapillary with some of them - who wanted to capture images of their neighborhood. There are plenty of caveats, of course, and there are parents around to keep them grounded.

I should seriously plan for a Mapillary field-trip idea for kids.

Such entertaining steps to create a wiki account to fix errors on the OpenID entry.

cannot find a confirmation code to save

good job SECURING ERRORS

A principios de septiembre nos estábamos enfrentando a algunos de los huracanes más fuertes del Caribe en las últimas décadas, el equipo de mapeo humanitario HOTOSM ya estaba colaborando a toda velocidad para ayudar a crear mapas en las áreas donde los datos eran limitados o inexistentes. Pocos días después los estados del sur de México estaban siendo golpeados por el primer terremoto, Oaxaca y Chiapas son conocidos por ser estados con una gran población marginada, en la comunidad de OpenStreetMap hemos estado discutiendo anteriormente sobre la necesidad de crear mapas detallados para estos estados que carecen de datos libres y abiertos de sus poblaciones. Los voluntarios de la comunidad de OpenStreetMap México solicitaron ayuda a HOTOSM para crear tareas y así agregar datos valiosos como edificaciones y carreteras en las ciudades y localidades donde la ayuda era más urgente. Una de las ciudades más afectadas fue Juchitán

En ese momento creamos un grupo de Telegram llamado #TerremotoMexicoMapping en el cual voluntarios de la comunidad OSMMX y estudiantes que habían participado en talleres en la Universidad del Estado de México comenzaron a colaborar creando archivos Geojson y mapeando pueblos y ciudades de Oaxaca y Chiapas, no éramos más de once personas en el grupo. Para el 15 de septiembre ya se han cartografiado 984,312 objetos en Juchitán, Ixtepec, Matias Romero, San Mateo del Mar, Pijijiapan, Tonalá, entre otras localidades (encuentre la lista completa en http://bit.ly/MXEarthquakeMapping estos Datos abiertos geográficos crowsourced ya se encontraban disponibles en el Base de Datos Abiertos geográfica más grande del mundo, OpenStreetMap prácticamente de forma inmediata al guardar el changeset. Mapping en Oaxaca y Chiapas despues del terremoto de 8.1M

Personas con experiencia en este tipo de eventos, como Daniel Orellana de la comunidad #MappingEcuador y los amigos de Kathmandú Living Labs (KLL), con gusto compartieron sus experiencias así como comunicaron lo que funcionó para ellos y así asegurarnos de no perder tiempo muy valioso. La herramienta de Quakeinfo.org mostrada por KLL era algo que ya tenía pensado Leo Castañeda por el conocimiento obtenido al mapear los incidentes de tráfico de Repubikla y sería la base para mapa.sismomexico.org

En menos de lo que pensamos, el segundo terremoto nos sorprendió afectando a la Ciudad de México, Morelos, Puebla, Estado de México y Guerrero, se agregaron más tareas a la Wiki estábamos agobiados por la cantidad de daños que enfrentamos y necesitaban ser mapeados pero al mismo tiempo el segundo terremoto hizo que las personas que no reaccionaron en el terremoto del 7 de Septiembre quisieran participar en cualquier cosa posible. Se crearon más tareas de mapeo por voluntarios digitales de HOTOSM y convocamos en un twitter a personas que tenían experiencia en Visualización y Análisis de Datos que se unieran a nuestro grupo de Telegram. De 11 personas, en pocos días el grupo tenía más de 150 personas interesadas en crear mapas y análisis de datos. Una de las tareas más difíciles fue mapear las áreas afectadas de la Ciudad de México debido a la alta densidad de edificios. Si la Ciudad de México tuviera un Catastro abierto, más voluntarios digitales podrían ayudar a analizar los datos en beneficio de la CDMX, lamentablemente los datos tienen acceso restringido y está reservado para su posible apertura ¡hasta el año 2023! (pero esto es material para otro blog).

El 20 de septiembre se lanzó mapa.sismomexico.org, al principio se pensó que sería una herramienta para agregar reportes así como agregar / recopilar bases de datos abiertas creadas por otras fuentes, pero nos dimos cuenta de que teníamos una debilidad, no teníamos suficientes personas para verificar / validar los informes. Por lo tanto, de una herramienta para crear informes, decidimos consolidar las fuentes en un único mapa y facilitar el proceso de descarga para hacer accesibles los datos generados, de modo que las organizaciones de ayuda y ciudadanos pudieran beneficiarse de las bases de datos. El increíble equipo de Verificado19S estaba haciendo un trabajo formidable validando los datos con su ejército de voluntarios, así que cuando las personas querían agregar algo a nuestro mapa, dábamos los detalles de Gaby Marquez de HorizontalMX y evitábamos una doble recolección de datos.

Todas las acciones podrían no haber sido posibles sin el compromiso de individuos e instituciones que creen en el potencial del proyecto OpenStreetMap, como los que se mencionan a continuación:

• Humanitarian OpenStreetMap Team-HOTOSM quienes apoyaron las activaciones desde el primer instante.

• La Fundación OpenStreetMap Colombia en la que Freddy Rivera ayudó a coordinar la activación de la Carta de Desastres de las Naciones Unidas Disaster Charter en la cual la UAEMX y La UNAM están haciendo que sus expertos ayuden a analizar las imágenes después del desastre y de esta manera identifiquen edificaciones dañadas a través de donaciones de imágenes satelitales.

• Kevin Bullock y el equipo de Digital Globe que liberaron imágenes PRE y POST desastre para ayudar a mapear las áreas afectadas.

• Estrategia Digital Nacional que apoyó las solicitudes de donaciones de imágenes que necesitaban UNITAR y Digital Globe. OpenAerialMap que procesó las imágenes satelitales para hacerlas accesibles para todo mundo.

• Codeando Mexico que nos brindó el apoyo para hostear y liberar mapa.sismomexico.org.

• Escuela de Datos por compartir y promover los mapeos.

• Pierre Béland apoyando con su experiencia y herramientas estadísticas.

• Mapatones que se llevaron a cabo en todo el mundo para ayudar a mapear y validar las tareas humanitarias:

  • Cartong en París,
  • CARTO en Nueva York.
  • Estudiantes de la University of Miami
  • Geoinquietos de la Universidad Politécnica de Valencia
  • Mapbox,
  • Telenav,
  • Accenture Colombia.

• Aplicaciones que generan imágenes a nivel de la calle como Mapillary, que coordinó a voluntarios para crear imágenes de edificios dañados en la Ciudad de México, Morelos y Chiapas y OpenStreetCam, quienes realizaron recorridos de Juchitán e Ixtepec para documentar el daño en el área.

• Desde Openstreetmap-México team, participaron activamente en la coordinación, difusión, construcción de proyectos, mapeo y validación, capacitación y acompanamiento de mapeadores: Juan Manuel Vázquez, Ricardo Pérez, Ruben Fernandez, Leonel Castaneda, Edgar Lemus, Cuauhtémoc Gutierrez, Miriam Gonzalez, Céline Jacquin.

Y especialmente gracias a lxs más de 1400 voluntarixs que agregaron una casa, una edificación, una carretera o un refugio al mapa, cada edición marca la diferencia para lograr más de 250,000 edificaciones mapeadas y casi 25,000 kilómetros de carreteras desde el 7 de Septiembre.

Gracias a todo el apoyo digital ahora tenemos datos abiertos y gratuitos disponibles para que todas las personas los utilicen, no importa si eres Voluntario, Estudiante, Gobierno, Universidad, Geek, Entusiasta de datos, todo mundo es parte de este movimiento y puede aprovechar los datos abiertos creados.

¡Nuevamente Gracias! Pero ahora ... ¿qué sigue? Haz clic aquí para descubrir

---English Version---

Early September we were facing some of the strongest hurricanes in the Caribbean ocean over the past decades, the humanitarian mapping team HOTOSM was already collaborating full speed to help creating maps in the areas were data was limited or nonexistent. Suddenly the Southern states of Mexico were hit by the first earthquake, Oaxaca and Chiapas are well know for being states with a large marginalized population, in the OpenStreetMap community we have been discussing in the past the need of creating detailed maps for these states among others who lack of this data. Volunteers in the Mexico community requested help to HOTOSM to create tasks to map valuable data for buildings and roads in the towns where help was needed the most. One of the cities more affected was Juchitan

At that time we started a telegram group name #TerremotoMexicoMapping in the one volunteers from the OSMMX community and students who had participated in workshops in the University of the State of Mexico started collaborating creating Geojson files and mapping villages of Oaxaca and Chiapas, at that time we were no more than eleven people in the group. By September 15th there were mapped 984,312 objects in Juchitán, Ixtepec, Matias Romero, San Mateo del Mar, Pijijiapan, Tonalá, among others localities (find the complete list in http://bit.ly/MXEarthquakeMapping this crowsourced geographical Open Data was available in real time in the largest geographical Open Data Base in the world, OpenStreetMap, as soon you click “save changeset” the data is available for everyone to use.

Mapping Oaxaca and Chiapas after 8.1M Earthquake

People with experience in earthquake response mapping such as Daniel Orellana from the #MappingEcuador community and the friends of Kathmandú Living Labs (KLL) were happy to share their best practices and communicate what it worked for them and make sure we don’t lose precious time. The Quakeinfo.org tool showed by KLL was something already Leo Castañeda was preparing by the knowledge gained in mapping Repubikla traffic incidents and was going to be the base for mapa.sismomexico.org

Without having a break the second earthquake surprised us affecting Mexico City, Morelos, Puebla, State of Mexico and Guerrero, more tasks were added to the Wiki we were overwhelmed by the amount of damage we were facing and needed to be mapped but at the same time the second earthquake make people who didn’t react on the September 7th earthquake wanted to participate in anything possible. More mapping tasks were created by digital volunteers from HOTOSM and we asked in a twitter for people who had experience in Visualization and Data Analysis to join our Telegram group, from 11 people in just a few days the group had more than 150 people interested in creating maps and doing data analysis. One of the hardest tasks was to map the affected areas of Mexico City due to the high building density, if Mexico City had an Open Cadastre more digital volunteers could help to analyze the data in the CDMX’s benefit, unfortunately the data has restricted access and it is reserved for opening until year 2023! (but this is a topic for another blog).

On September 20th mapa.sismomexico.org was launched, at the beginning it was thought to be a tool to add reports and also add/gather open databases created by other sources but we realized we had a weakness, we didn’t have enough people to check/validate the reports so from a tool to create reports we decided to consolidate the sources in one single map and make easier the download process to make accessible the data generated so relief organizations or citizens could take benefit of the databases. The amazing team of Verificado19S was doing an incredible job validating the data with their army of volunteers so when people wanted to add something to our map we would give the details of Gaby Marquez from HorizontalMX and avoid a double collection of the valuable data.

All the actions could have not been possible without the commitment of individuals and institutions that believe in the potential of the OpenStreetMap project, such as:

• Humanitarian OpenStreetMap Team- HOTOSM who supported the activations since the first moment.
• OpenStreetMap Colombia Foundation in the one Freddy Rivera helped coordinated the Disaster Charter from United Nations activation in the one the UAEMX and UNAM are having their experts helping to analyze images post disaster and this way identify damage buildings through satellite images donations.
• Kevin Bullock and team from Digital Globe who released PRE and POST disaster images to help with the mapping of the affected areas.
• Estrategia Digital Nacional who supported the imagery donations requests needed by UNITAR and Digital Globe. OpenAerialMap who process the satellite images to make them accessible.
• Codeando Mexico that gave us the support to host and deploy mapa.sismomexico.org.
• Escuela de Datos for sharing and promoting the mapping.
• Pierre Béland always supporting with his expertise and statistics tools.
• Mapathons all around the globe took place to help mapping and validation of the humanitarian tasks:
  • Cartong in Paris. *CARTO in NYC.
  • Students from University of Miami.
  • GeoInquietos from the Universidad Politécnica de Valencia.
  • Mapbox.
  • Telenav.
  • Accenture Colombia.

• Street level solutions such as Mapillary who coordinated volunteers to create images of damaged buildings in Mexico City, Morelos and Chiapas and OpenStreetCam who took tracks of Juchitán and Ixtepec to document the damage in the area.

• From Openstreetmap-México team, Juan Manuel Vázquez, Ricardo Pérez, Ruben Fernandez, Leonel Castaneda, Edgar Lemus, Cuauhtémoc Gutierrez, Miriam Gonzalez and Céline Jacquin have participated actively in coordination, diffusion, projects construction, mapping and validation, capacity building and orientation to new mappers

And specially thanks to the 1400+ volunteers who added a home, a road or a shelter to the map, every edition make the difference to achieve over 250,000 buildings and almost 25,000 kilometers of roads since September 7th 2017.

Thanks to all the digital support, now we have Open and free data available for everybody to use, it doesn’t matter if you are a Volunteer, Student, Government, University, Geek, Data enthusiastic, everybody can take advantage of the open data created.

Thanks again!

Collaborators of the OpenStreetMap Mexico team

But now…what is next? Click here to find out

NSDI Field Data Collection workshop

NSDI Sri Lanka is conducting five workshops for government field officers representing Agrarian Services Department, Land Use Policy Planning Department, Archeology Department and Local Authorities. All five workshops are conducted as two day sessions.

In this training participants have been trained on basic concepts of Spatial Data, GIS and some open source data collection tools. First day training is on theories and some applications. Second day training is on how to use OSM for field data collection and management.

https://www.facebook.com/permalink.php?story_fbid=1347594545368784&id=1132399976888243

In Attendance:

• SF Sarah
• Neocobalt
• Minh Nguyen
• Luke W
• 3vivekb
• Nick
• Betsy

Project Selection:

As a group moving forward we all agreed to continue to support and finish San Jose sidewalks import but if a Santa Rosa fire mapping project spun up we would all shift focus, at least temporarily.

Minutes:

We discussed some reverting issues from the National Day of Civic Hacking.

3vivekb went into detail about how he set up the sidewalks import and processed the data and all the help Minh Nguyen provided.

We talked about keyboard shortcuts in JOSM (6 to zoom in on issues, hitting M to merge points) to speed up the sidewalks project.

Minh talked about phone books and coverage % as well as about the coming SOTMUS conference.

Cet article est une mise en avant d'un site de mon maître-contributeur JeaRRO.

L'idée

L'idée de départ était la suivante :

"Si je veux intégrer les monuments historiques, dans mon secteur, que dois-je faire, par où commencer ?"

Le but du site est donc de référencer tous les monuments historiques français en se basant sur une partie de la base de données Mérimée du Ministère de la Culture, de Wikipédia et d'OpenStreetMap via le tag 'mhs' et en fournissant une aide à la cartographie, sympa !

Cela donne un référencement de 44 662 monuments et, bonne nouvelle, plus de 60% sont déjà cartographiés dans OpenStreetMap, et si on arrivait à 100% ??

Utilisation du site

Le site est très facile d'utilisation et le référencement encore plus simple.

• Se rendre sur le site : http://wom.jearro.fr/
• Dans le champ au centre, choisir un département puis 'Lister les monuments'

• Pour chaque monument, on a accès :

  • à la base Mérimée avec son lien direct (Exemple)
  • à la page Wikipédia du monument (Exemple)
  • à une proposition de 'tags pour OSM' :

• Dans cette même fenêtre, vous pouvez avoir une localisation précise ou fortement imprécise ; un travail sur le terrain peut-être nécessaire !

• Enfin, vous pouvez cliquer 'Charger la zone dans JOSM' qui permet d'ouvrir la zone dans le célèbre logiciel.

On remarquera enfin la colonne commentaires qui permet de savoir si la page Wikipedia est inexistante, si la localisation n'est pas présente...

Techniques utilisées derrière le site

La carte en page d'accueil utilise Map-Contrib : https://www.mapcontrib.xyz/.

Dans cette carte, les monuments existants dans OpenStreetMap sont repérés en vert et s'affichent via une requête sur overpass-turbo, d'où une certaine lenteur ; peut-être même que vous n'aviez pas vu ces monuments verts :)

Pour les monuments en rouge, inexistants dans OSM, il s'agit d'une extraction CSV synchronisée chaque nuit.

Les bonnes pratiques

Les tags fournis ne sont qu'une proposition. Ainsi :

• Certaines propositions de 'name' peuvent être différentes (prises dans Mérimée), vérifiez au préalable ce que vous écrasez et utilisez le tag 'alt_name' ou 'old_name'
• Sauf en cas d'erreur évidente, on laisse en l'état. On n'efface pas le travail de quelqu'un d'autre.
• Pour les églises, il n'y a souvent pas de nom, du coup, on peut aller voir manuellement le lien Wikipédia qui les donne plus fréquemment.
• Il est parfois nécessaire de compléter ou ajuster les tags avant de coller les tags avec le raccourci CTRL+Maj.+V dans JOSM.

Et mon département dans tout cela ?

Si vous souhaitez voir les statistiques, c'est sur cette page que cela se passe.

• Le premier graphe fourni le pourcentage de Monuments Historiques cartographiés dans OSM et dans Wikipédia.

• Le 2ème fournit l'évolution de la cartographie et le pourcentage restant à faire.

Aujourd'hui, 13 octobre 2017 :

62.63% des Monuments sont cartographiés dans OSM et 47.61% dans Wikipedia.

A vous et bonne cartographie !

Hola de nuevo, aquí compartiendo un poco de lo que he venido avanzando estos últimos meses. He estado haciendo aportes en la ciudad de Arequipa y alrededores. Entre los más resaltantes podría citar la correción y adición de rutas de trocha en las cercanías del volcán Misti, mapeo de una línea de alta tensión que parte de la central ubicada en el distrito Socabaya, recorre parte de la provincias de Arequipa y Caylloma con dirección al norte. También se prosiguió con el mapea de terrenos de cultivo en los distritos de la periferia de la ciudad, aunque en menor medida que antes. En este mes planeo retomar esto último empezando por los distritos de Sabandia y Mollebaya, donde hay lugares muy bonitos que he ido conociendo aprovechando algunas caminatas que he hecho por la zona de Yumina. Espero pronto poder dar un vuelta por la parte de Mollebaya para conocer y de paso verificar como es la geografía de la zona. Hasta entonces...

da oggi, terrò traccia del lavoro di aggiornamento della mappatura Sentieristica . Mi chiamo Lorenzo, abito sul Montalbano , catena montuosa compresa tra le province di Prato , Firenze e Pistoia. Gestisco il sito ( e futura associazione ) www.montalbanotrail.it

For full meeting details, read here - https://www.freelists.org/post/ilugc/ILUGC-monthly-meet-Saturday-14-Oct-2017

Indian Linux Users Group, Chennai [ ILUGC ] October Meet - 14 Oct 2017

Venue: Classroom No 1, Aerospace Engineering, Near Gajendra Circle, IIT Madras. Link for the Map: http://bit.ly/iitm-aero

Time : OCt 14, 2017 3.00 - 6.00 PM

Talk - 2

Mini workshop using a TelegramBOT to translate strings for OpenStreetMaps.org

We are dreaming about Maps in Tamil, for long time.

Imagine your mobile phone or GPS device, shows the maps in Tamil, displays the roads, interesting places in Tamil, It shows routes and says the street names and directions in Tamil while driving.

The dream can come into real as we have most of the required technologies. OpenStreetMaps to provide maps, many apps like streetcomplete, osmcontribute to add streetname and interesting places, Tamil TTS to say everything in tamil.

The major thing we need is we need all the strings in Tamil. OSM supports language tags and we can give any string in any language, along with its translation on other languages.

To enable the translation process of existing strings in OSM, we are working on a telegram bot. Now, it is easy to contribute to OSM via translation, with mobile or with web browser.

The bot will be released for public tomorrow with its source code.

It will ask for your osm username, and then for translate or verify. The strings will be translated by google translator as first step. That is not perfect fully. so, we need people to verify it,

You can see a string with its translation. Then say it right or wrong. once three people confirmed a string it as right, it will be confirmed. The incorrect strings will be displayed for translation.

Once the strings are completed, they will be uploaded to OSM using a bot account.

Will release the bot tomorrow.

Come with

• your smartphone.
• Install Indic Keyboard or Sellinam for Tamil Typing.
• Register at openstreetmaps.org

Let us have a translation workshop for openstreetmaps.org

Thanks for the team.

• Dinesh Karthik - dineshkarthik.r@gmail.com
• Srikanth Logic - srik.lak@gmail.com
• Syed Khaleel Jageer - jskcse4@gmail.com
• Shrinivasan - tshrinivasan@gmail.com

Duration - one hour

More accurate informations for the city of Shkodra:

• buildings: validation, number, level, update (new/old object)
• highways (more accurate) improvement, names, categories, speed limit, validation, update (new/old object)
• bicycle line (update)
• parking area (update)
• update tourism category (hotels, hostels, guesthouses, camping, attractions, hiking/biking routes around Shkodra)
• update the POI's (new entries)

More accurate information for "North Albania" (touristic villages like Theth, Valbona, Curraj Epërm, Lëpushë, Vermosh, Bogë, Vukël, Nikç, Tamare, Razëm, Prekal, Shala River, Mazrek, Drisht, Velipojë, Shirokë, Zogaj, Rrjoll, Zadrimë area, Ana e Malit area, around Gashi River):

• new/update hiking/biking routes (more accurate type of hiking routes T1-T5)
• new/update guesthouses
• attractions

Fazer correções e ajustes a permissões de trânsito, sentidos, faixas e inserção de semáforos. Objectivo, obter um roteamento rodoviário correcto em Alvito, Torrão, Évora, Vila Nova da Baronia, Odivelas e Viana do Alentejo. Validação e testes com OSRM

From time to time I participate in the voting of tagging proposals. Even if I lack the necessary knowledge in the field the proposal is about (e.g. I have limited knowledge about electricity or fire hydrants), I check a few things before I cast my vote. (The following is my personal opinion)

Avoid changing heavily used tags

A proposal should always avoid to change existing tags which are used a lot. There are some reasons for a change of the tagging but they are rare. Changing American English to British English just to have British English is one example if there is no other benefit. Changing from or to namespaced keys/values is another.

If the only reason is to have nicer keys/values, this will just lead to an unnecessary workload for multiple parties. Mappers who attempt to do mechanical edits, other users who revert them, the Data Working Group who has to mediate disputes (or has to revert the changes if it has not been done already), and last but not least data consumers who have to change their software. You might think "Data consumers, don't be angry, you have just change a string (and add an AND to your code)" but you should keep in mind that more and more data users order pre-installed servers/services from companies in the OSM ecosystem. Their services get automatic data updates because they want or need data being up to date but they will miss more and more features. And all this just happens because someone thought that an l is missing in jewellry (I am not sure if that was a joke or test).

If a proposal tries to change a heavily used tag, I think that it has to address why this change is really necessary and that the "cost" of the change are lower than the benefits. Mentioning this only in one or two sentences will lead to a failure of this test (except very long sentences). If a proposal fails this check, I will say NO although other parts might be good.

Well formed keys and values

If check number 1 is passed, I will check if the new tags and values are well-formed. Keys must only contain lower-case characters, underscores and, if really necessary, numbers. Colons are namespace delimiters. You must have really good reasons that I accept upper case characters. Spaces and other characters are a no go.

The same applies for values. Only free-text values may have any content.

Boolean values must be no or yes.

This check must be passed, too. A failure results in a No vote.

Good tag design

Good tag design is more difficult. It is a good idea to put special interest tags into a namespace but on the other hand namespaced keys exclude mappers who don't think they are qualified to edit them.

Namespaced keys have the advantage of avoiding conflicts with other keys which could be tagged on the object. On the other hand, namespaces add some kind of noise to the raw tag list.

Using keys to tag properties of the new feature B which are already in use for feature A is not a good idea if an OSM object could be both A and B but the value of the key should be different.

Example: A pole of a power line (power=minor_line) has a reference number ref=34. A proposal wants to add a tag to map transformators on poles. Both should share one node in OSM. Adding the reference number of the transformator as ref=T5 is not possible because this would overwrite the reference number of the pole. Adding a special tag for reference numbers of transformators mounted on poles is one solution. The other one is to map two nodes. Both have advantages and disadvantages.

This example shows that there is not always a clear answer what good tag design is and therefore serious problems have to persist after the discussion to make the proposal fail this test.

Observable

A tagging proposal should only suggest tags which are observable on the ground. For example, a proposal which contains a tag for the maximum amperage a electrical locomotive may consume from the catenary, might fail this test if the author could not point me to a region where it can be observed on the ground (in Germany you cannot observe it).

If a property or feature can be observed only on some objects, this will not cause a failure of this test.

Stable

Tagged values have to be stable. If values changes multiple times per year (or even every year), maintenance is difficult or impossible. If the value changes too often, the property does not fit into OSM at all.

This is a soft fail test, too. If the properties of some instances could be stable but other are not, it might not lead to a No vote.

Privacy

Tagging proposals which invite mappers to add information which infringes privacy and/or will lead the project into legal trouble in regard with data protection (in Europe) could fail this test. It depends on how much tagging without infringing privacy is possible (see "Stable" and "Observable").

For example, a proposal with a tag for the owner of a house will clearly fail this test.

Structure

This is a soft test. Readers of a proposal should understand quickly what the proposal wants to change, what it introduces and what is just mentioned as context to understand the proposal. Guides which summarize various tagging schemes fail it easily because proposal are not guides but change requests. If a guide covers a disputed topic, it is a good idea for its author to write that it is disputed, what the parties arguments are and leave the decision to the reader.

Split up your proposal into a section of simple and advanced tagging if your proposal is very long and goes deep into a topic of a special interest. People starting adding the simple features and properties might later use the advanced tagging. But if you only offer a steep ladder, less people might climb it up.

Summary

As you have seen, I am very strict because there is no difference between a YES and a partial YES. But you, as a proposal author, could circumvent this problem partially. If you split up your proposal in two or more parts, the parts which don't fail these test, will pass.

If you want to learn more about how to write good proposals, I suggest you to read the discussions and voting section of rejected proposals.

What do you check if you read a proposal before you cast your vote? Or does your wiki user page already include the UserAgainstTagVoting or No_Wiki_Fiddlers template?

مجتمع تجاری و کارگاهی مهندس شعلی بر

Recently we released the new version of OSMCha, an application to help the OpenStreetMap community to review the changesets in the map. In this new version, the frontend was rewritten, we changed the backend to serve the data as a REST API and we have added some new interesting features. Let’s talk about some of the new possibilities that came in with these changes.

The REST API allowed us to build a faster and more efficient frontend and it opened up avenues for other applications being able to use OSMCha data. Yes, It’s now possible to build a JOSM plugin to update the status of a changeset or a feature in OSM. The API documentation to make this happen can be found here → https://osmcha.mapbox.com/api-docs/

The main API endpoint is the /api/v1/changesets/ as it allows us to get changesets. It accepts many filters and one ordering parameters. We also have some sub-urls, like /api/v1/changesets/checked/, /api/v1/changesets/unchecked/, /api/v1/changesets/suspect/, etc. That makes it easy to filter the changesets by some boolean fields and accepts filters parameters too.

Filters & Areas of Interest (AoI)

The new version of OSMCha comes with many additional options of fields to filter changesets that weren’t present in the previous version. Almost all filter options are available in the frontend, but you can also check the API docs to verify if you can benefit from some special API capability. One resource that is not still unavailable in the frontend is the possibility to filter changesets by using any geometry type you want, not just limiting to a bbox.

Furthermore, now you can set a filter query and save it as an Area of Interest (AoI), that way you won’t need to set the query parameters again, all you need is to access your AoI URL. Each AoI also has a GeoRSS feed that you can use to be notified for the new edits. You can also easily share your AoIs with other users by sending them the URL.

To save an Area of Interest, make a POST request to its endpoint with the name you want to give to your AoI and the filter parameters, which are the same that we use to query the changesets. The API also supports saving an Area of Interest with any geometry type you want.

Statistics

Do you need stats about an AoI, a user or about a changeset query? We provide it with some endpoints: /api/v1/stats/ gives us stats about the changesets (total number, quantity of harmful, checked and quantity by suspicion reason and by tag). This endpoints supports the filter params. We have the same stats to an Area of interest in /api/v1/aoi/{id}/stats/ and finally the stats of a user in /api/v1/user-stats/{uid}/.

Protection rules and documentation

The API has a throttling mechanism that limits the number of requests by user by minute to avoid our database of being misused. There are some endpoints, like the ones that add and remove suspicion reasons, that were made to help with administrative issues like fix a wrong detection and whose access is restricted to the admin users.

So checkout the documentation and use OSMCha to monitor your areas of edits! If you have some suggestion, feedback or ideas, post a comment or open an issue in github. It will be great to have new insights from the OSM community!

• API documentation: https://osmcha.mapbox.com/api-docs/
• API/Backend repository: https://github.com/willemarcel/osmcha-django
• Frontend documentation: https://osmcha.mapbox.com/about
• Frontend repository: https://github.com/mapbox/osmcha-frontend/

В этом посте я хочу обобщить все знания, известные мне по мапингу квартальной сетки леса. Думаю, другим будет тоже интересно, так как в лесу на самом деле полно того, что можно внести на карту.

Введение

Ещё не зная ОСМ, я по роду своего увлечения (лыжи, велосипед, бег) очень часто бывал в лесу и обращал изредка внимание на квартальные столбы, расположенные на перекрёстках просек. Познакомившись с проектом OpenStreetMap и набравшись немного опыта в картировании, мне в голову пришла идея о том, что неплохо было бы внести данные о столбах и соответственно о кварталах, в углах которых они находятся. Почитал форум и наткнулся на полезнейший пресет для JOSM от пользователя igitov, в котором есть всё, что нужно для картирования желаемых мне объектов и не только. Однако с места в карьер разобраться с этим не получилось, да и плюс ко всему желаемая информация не отображалась нигде. Совсем. Но мы же не рисуем под рендер, поэтому я потихоньку стал собирать информацию и путём проб и ошибок вносить её в ОСМ. Попробую поэтапно объяснить, как это делается.

Сбор данных

Для картирования лесных кварталов не подойдёт ни один спутниковый снимок - вернее, просеки-то может быть и будут видны, а вот нумерацию нужно уточнять на местности. В некоторых регионах бывают ещё и карты квартального деления по лесничествам, но насколько они правдивы и можно ли оттуда копировать информацию - вопрос спорный. Я для наших пензенских лесов находил карты с номерами, но старые, и при проверке на местности многие из кварталов были уже перенумерованы. В черте г. Пензы тоже есть леса, и там нумерация вообще своя, карт вообще нет. Поэтому любая покатушка/поход сопровождалась поиском столбов и внесением данных по ним посредством аудиозаметок в OSMAnd.

Если кто не знает, квартальный столб выглядит так: Подходим к столбу, берём в руки компас (так как совершенно не факт, что север будет между двумя меньшими цифрами), и указываем в заметке в OSMAnd/в обходном листе, в сторону какой части света смотрит та или иная щёчка столба. Походили/покатались, пособирали циферки со столбов, - и домой, за JOSM. Если в редакторе уже стоит лесной пресет, то идём в "Лесные кварталы и просеки" - "Квартальный столб", и отмечаем номера на щёчках в соответствии с частями света, в сторону которых они направлены.

Квартальные просеки, как правило, делят лес на прямоугольники, реже на другие фигуры. Если известно, что в вашем лесу всё красиво и все просеки есть в ОСМ хотя бы как грунтовые дороги (highway = track), то можно рискнуть и обозначить квартал, если вы знаете хотя бы один из угловых квартальных столбов. В этом случае номером квартала будет являться номер на щёчке столба, обращённой к углу нужного квартала. Если же вы не уверены, то лучше побывать в лесу ещё раз и постараться обойти квартал полностью. Как правило, столбы стоят на каждом из угловых пересечений, весной и осенью ходить всегда проще, когда даже в самую чащу можно залезть и пройти по самой заросшей просеке. Как вариант ещё - ранней весной по насту на лыжах, тоже хорошо.

Внесение результатов

Итак, со столбами вроде как разобрались. С кварталами будет чуточку посложнее, но не более того. Прежде всего в JOSM нам надо нарисовать границы кварталов, и в большинстве случаев этот момент не вызовет сложности - в большинстве лесов, как уже было отмечено выше, квартальные просеки отмечены дорогами, для пущего уточнения можно ещё добавить к дороге man_made = cutline (есть в лесном пресете "Просека"). Нужно только разделить вей на кусочки и выделить их так, чтобы получилась замкнутая линия:

Затем идём в лесной пресет и там выбираем "Лесные кварталы и просеки" - "Лесной квартал". Пишем номер нашего квартала, если была перенумерация и известен старый номер - можно указать и его, в строке "Оператор" при желании можно указать лесничество, в чьём ведении находится данный квартал. Нажимаем "Новое отношение".

Видим, что у нас создалось отношение boundary = forestry_compartment с номером 329, а внизу слева сгруппировались линии - границы нашего квартала. Ещё нужно, чтобы линия в центре редактора отношения была замкнутой, для этого надо выделять линии, составляющие квартал, по порядку (по часовой стрелке или против - неважно). Теперь добавим в наше отношение ещё пару необходимых тегов: type = multipolygon и name = 329, а каждой составляющей границы квартала назначим роль outer:

Готово! Нам осталось нажать ОК и при включённом слое "Лес" мы сразу же увидим наш квартал с номером. Теперь можно двигаться дальше или выгрузить результаты работы на сервер. Если у вас OSMAnd, то на следующий день можно скачать свежую карту и полюоваться на своё творение - номера кварталов рендерятся, к сожалению, пока без границ, но зато на всех слоях (кроме, кажется, UniRS). Столбы квартальные отображаются как POI, но только простым оранжевым кружком, значка для них пока не придумали. На скриншоте стандартный стиль OSMAnd, 13-й масштаб, минимальный для отображения нумерации.

И всё?

Нет, не всё. Квартальными столбами лес не ограничивается. В OSM можно вносить информацию и о деляночных столбах, они интересны с точки зрения больше познавательного, чем практического, но иногда бывает так, что квартальных столбов нет на перекрёстках просек (сгнили, украли и т.п.), а деляночные есть, и они помогают тогда в установлении "личности" квартала. Деляночный столб вносится почти также, как и квартальный, только в большинстве своём у него одна щёчка и отмечается он как signpost = forestry_allotment ("Деляночный столб" в лесном пресете). На щёчке - полная информация о проводимых на ограниченном столбами мероприятиях. Рассмотрим пример.

В первой строке указывается номер квартала и делянки, во второй - мероприятие аббревиатурой и год проведения, в третьей - выдел и площадь в гектарах. Соответственно, взглянув на столб в примере, мы можем сказать, что в 145 квартале на 8-й делянке в 2017 году проводилась ССР - Сплошная Санитарная Рубка, мероприятие затронуло первый выдел на площади в 5 га. Разумеется, в JOSM все три строки умещаем в одну вот так:

А вообще, аббревиатур мероприятий очень много, и хотя вроде существует какой-то ГОСТ по ним, иногда пишут, кто во что горазд, даже и не поймёшь, что здесь было. Лично мне чаще встречаются следующие обозначения:

• СРВ/СВР/РСВ/ВСР - санитарная рубка выборочная;
• ССР/СРС - санитарная рубка сплошная;
• ЛК - лесная культура, иногда с первой буквой породы: ЛКБ - берёза, ЛКС - сосна, ЛКЕ - ель и т.д.;
• УЗ - уборка захламлённости;
• ПРЧ - прочистка;
• ПРХ - проходная рубка;
• ПП - пробная площадь (посадка).

В случае с лесной культурой, если есть указание на породу, можно участок, ограниченный деляночными столбами, описать как лесопосадки с указанием породы и годом посадки.

Вот и всё, чем хотелось бы поделиться по теме картирования квартального деления лесов. Тема очень интересная, и я надеюсь, она будет развиваться, ведь чем лучше наши леса будут закартированы, тем меньше шансов, что в них кто-то снова заблудится.