Users' diaries

Recent diary entries

24 hours to rebalance the OSM Foundation's governance

Posted by Stereo on 14 November 2018 in English (English)

The OpenStreetMap project is organized on an international level by the OpenStreetMap Foundation, under British law.

Some companies are paying employees to join, and there are rumors that they give voting instructions.

In recent years, the Board has gradually lost its balance. Over-representation of some areas and groups makes it difficult to maintain a balanced and diversity of government action and raises some conflict of interest issues. Therefore, it is important that all kinds of mappers join in to balance things out.

On December 15 there are board elections, and everyone who was a member before November 15 can vote.

489 ballots were cast during the last election. By way of comparison, in the last few days, 17 employees from a single US company have joined. This might not be anything sinister, but it's worrying especially shortly before the board election, and getting the largest amount of OSMF members is the best safeguard of balance. is the form. It costs £15 (about €17 or $20), it takes 4 minutes, it's important and it's too late in 24 hours. I am a candidate for the board election, but of course you distribute your votes however you want.

Location: Geesseknäppchen, Hollerich, Luxembourg, Canton Luxembourg, 1265, Luxembourg

Two small Potlatch 2 updates

Posted by Richard on 14 November 2018 in English (English)

Last week there was a small change to the API which means some GPS traces are now returned unordered whereas previously they may have been ordered. This obviously has implications for editors' GPS display. Potlatch 2 now copes with this by doing some basic proximity testing in an attempt to 'reorder' the unordered points, which restores the GPS layer to some degree of sanity.

At the same time, I took the opportunity to fix something that's been bugging me for months. Historically, Potlatch 2 draws all the features crossing the current viewport, and then removes the sprites when they're no longer visible. This is fine except when you pan across a 2000km power line, which takes ages to draw as a dotted line at z19, and bogs down Flash's display performance for evermore. For such large objects, P2 now only draws the on-screen part, which makes it a whole bunch snappier.

Details added to NE Philly Fox Chase section

Posted by PhillyDave on 14 November 2018 in English (English)

I spent some time clarifying the Fox Chase-Newtown branch of the old Reading Company, currently the Fox Chase SEPTA commuter rail branch. It starts at Shady Lane and continues to Country Line Rd. as two separate agreements between SEPTA and Montgomery County. Anticipating a 2019 agreement between SEPTA and the City of Phila. for the section between Rhawn St. and Shady Lane.

Dirty datasets

Posted by Cascafico on 14 November 2018 in Italian (Italiano)

Mini abstract

I've found a 600+ rows Bed&Breakfast dataset, available opendata by RAFVG. No geo coordinates, so I decided to go for geocoding.

To get reliable coordinates I used csvgeocode script attached to nominatim geocoding service

Nominatim but it requires almost perfect (standardized) odonyms, ence I strarted openrefine and a reconcile service which comes in a separate jar.

Reconcile service needs a csv with authoritative names, which I get from overpass-turbo and some filtering.


Bed and Breakfast is a rather new dataset (Oct 17) with more than 600 POIs. Many useful fields such as

  • name and operator
  • phone
  • email
  • site
  • opening hours

Cleaninig data

Such duty has been accomplished by OpenRefine and Reconcilie, connected as a reconciliation service,

In order to standardize B&B addresses input by operators theirselves, I had to provide Reconcile with an authoritative set of highway names, which I got from overpass-turbo (see Strade d'Italia diary entry


Just happened for other projects, I choose csvgecode which features pretty simple usage.

Here is a run using mapbox service:

$ csvgeocode input.csv output.csv --handler mapbox --delay 1000 --verbose --url "{{INDIRIZZO}},{{CAP}} {{COMUNE}}.json?access_token="

here using nominatim, instead:

$ csvgeocode input.csv output.csv --handler osm --delay 1000 --verbose --url "{{INDIRIZZO 1}}, {{COMUNE}}&format=json"

Rows geocoded: 468
Rows failed: 114
Time elapsed: 879.4 seconds

Mapa rodoviário de Mato Grosso

Posted by erickdeoliveiraleal on 13 November 2018 in Brazilian Portuguese (Português do Brasil)

Excelente mapa para obter referências das rodovias pavimentadas/rural do Mato Grosso, revisei algumas, mas há muita coisa pra checar.


Posted by Hokko-sha on 13 November 2018 in Japanese (日本語)



**太字** __ふとじ__ 太字 ふとじ

*斜体* _イタリック_ 斜体 イタリック




*** --- (どっちも水平線)



# 見出しH1


## 見出しH2


### 見出しH3


#### 見出しH4


##### 見出しH5


###### 見出しH6


  • できないこと
    • 打ち消し線
    • テーブル(表)
    • 文字の着色
    • その他色々…


Posted by Hokko-sha on 13 November 2018 in Japanese (日本語)


OSM Streak の取り組み

  • 続けることに意義がある → 大停電で途切れました orz
  • 毎日Twitter @Hokko_sha で垂れ流し中


  • 実走による道路修正
  • 字名
  • 農地トレース
  • バス停マッピング
  • Ingress & Resources で出向いたついでの周辺市町村現調によるマッピング



  • 初心者でも扱いやすいよう、壊しても修復しやすいよう市町村単位で分割
  • エラー修正


  • エラー修正
  • スーパーリレーションの整備



  • 2月
  • 10月


  • 8月 日比谷

マッピングパーティー in 富岡八幡宮



  • OSMの諸々は主にツイッターにて
  • @osmjp_hokkaidoのロック解除サポートに参加
  • 長文の定形コメントはツイ垢ロックされるのでほんとやめてほしい(やむを得ず山下さんが連投ブロックを設定して対処済み)


  • Google+にてIngressエージェント向けにOSM情報を発信
  • Nianticが1月以来マップを更新してくれないのでみんな飽きてやめていく…




Tracing the northern section of the P-9 highway

Posted by apm-wa on 13 November 2018 in English (English)

Ann and I celebrated the Monday holiday of Veterans Day, November 12, by driving out to Hauz Han about three hours east of Ashgabat, heading north on the P-9, then turning east on it to Mary. I had never been on that route and we collected two gas stations plus took lots of ground-level imagery using Mapillary. I will upload that imagery plus imagery collected on the P-25-to-P1 drive when we next come stateside and have access to high speed internet. I have already uploaded the GPX files Mapillary generates, however, so can tweak the highway itself as needed.

I used MAPS.ME to collect some POIs along the way, including marking some new U-turns on the M37. Turkmen Auto Roads State Concern is putting up guardrails to separate new dual carriageways, so mapping the U-turns is an ongoing effort. Some of the village and farmers association names have changed so I have more editing to do, updating names of municipalities to match the signage. Gulanly is now called Gokhan, for example, renamed in honor of one of the sons of the mythical Oguz Han, progenitor of the Turkic peoples. I tried to capture the signage on Mapillary.

We stopped for lunch at the Lebap Cafe in Hauz Han, to eat fresh fish (grass carp) deep fried in cottonseed oil. If you are in the neighborhood, I recommend the Lebap Cafe!

Location: Ahal Region, Turkmenistan

Inclusão de CEP´S no Bairro do Cordeiro em Recife/PE.

Posted by raphaelmirc on 12 November 2018 in Brazilian Portuguese (Português do Brasil)

Boa noite,

hoje vim relatar a inclusão de CEP´S no bairro do Cordeiro conforme venho fazendo atraves do Projeto Mapeia Recife que visa mapear a cidade do Recife com Cep Com base no CNEFE

Escolha o Estado para Baixar os CEP´S da Sua Cidade; Base de CEP´S (CNEFE) - IBGE.

Outros Link´s pode ser encontrado no Guia do OSM BR;

changeset/ do Bairro do Cordeiro - Recife/PE.

Mais informações, Noticias e tutorias acesse o Guia OSM BR.

Raphaelmirc Recife/PE.

A tool to display Wikimedia Commons categories with coordinates on the OSM map

Posted by Alex-7 on 12 November 2018 in English (English)

This tool can display on the OSM map as geo-markers:

  • Wikipedia articles which have coordinates for all language versions of Wikipedia

  • wikidata, wikipedia, and wikimedia tags from the OSM map database

  • Wikidata items which have coordinates

And now I added the possibility to display also the Wikimedia Commons categories which have got the geographical coordinates.

The tool is available via this link:

I created it for my personal needs, for my surveys, but, perhaps, it could be useful to others.

The tool is as simple as it could possibly be. Just click on the map and the geo-markers will appear on the map up to 10 km around the click.

In areas with many categories it makes sense to reduce the radius of the search, because the maximum number of displayed categories I limited to 100.

P.S. Only categories which are connected to a Wikidata item or Wikipedia article are displayed. I do not know how to display absolutely all categories with coordinates via MediaWiki API, or if it is possible at all. On the other hand, the categories which are not shown are usually the sub-categories of those main ones which are displayed.

But it is possible to add the tag wikimedia_commons=Category:* to an OSM object, and then it will be displayed via search in the OSM database (the 2nd option).

Melhorias na Cidade de Recife e Olinda em Pernambuco.

Posted by raphaelmirc on 12 November 2018 in Brazilian Portuguese (Português do Brasil)

fiz diversas melhorias nas cidades de Recife e Olinda e que pode ser conferida atraves das changeset que fiz as edições.

um forte abraço a todos os mapeadores.

divulgue e conheça o Guia OSM BR atraves do site.

Raphaelmirc Recife/PE.

Location: Santo Antônio, Recife, Microrregião de Recife, Região Metropolitana de Recife, Mesorregião Metropolitana de Recife, Pernambuco, Região Nordeste, Brasil

Inserindo Bairros na Cidade de Olinda e Paulista em Pernambuco.

Posted by raphaelmirc on 12 November 2018 in Brazilian Portuguese (Português do Brasil)

Hoje completei a edição dos Bairros que faltava nas cidades de Olinda e Paulista, pois esses dois bairros está bem mapeado mais estava faltando alguns bairros que não estava no Openstreetmap e hoje acabei adicionando os bairros que faltava, com isso as duas cidades estão com todos os bairros, ficando agora fazer uma revisão se falta mais algum bairro e adicionar os nomes de ruas que ainda não existe.

Cidade do Paulista/PE.

Cidade de Olinda/PE.

Conheça o Guia OSM BR acessando o Site;

Um Forte Abraço a Todos os Mapeadores Raphaelmirc Recife/PE

Location: Santo Antônio, Recife, Microrregião de Recife, Região Metropolitana de Recife, Mesorregião Metropolitana de Recife, Pernambuco, Região Nordeste, Brasil

MapRoulette 3.10 Release Notes

Posted by mvexel on 12 November 2018 in English (English)

MapRoulette 3.10 is now available on Here's what's new!

For Mappers

We made changes to the map layer selection. You can select more and more relevant background map layers in MapRoulette. The available layers are retrieved from the OSM Editor Layer Index. For aerial imagery layers, you can also select the Mapbox road overlay.

When browsing for Challenges, you can now sort the results different ways: by age, by popularity and 'smart' which also takes into account Featured Challenges and Challenges you saved. The old sorting by name is also still available.

Smaller improvements include support for Level0 as a preferred editor, more keyboard shortcuts and seeing the age of tasks when browsing Challenges.

For Challenge Owners

You can now use mustache tags in your Challenge description. These are placeholders for values that are unique for each task. For example, if you have a value lanes in your source task GeoJSON, you can add something like "We think this road has {{lanes}} lanes. Can you verify this using imagery and update OSM as needed?". When a task is shown to the mapper, the tag will be replaced with the appropriate value.

You can now organize the Challenge and Project administration screens the way you like them. All components are widgets you can drag, remove, and add. You can even create different views to see different sets of information at a glance.

We also support a new streamable GeoJSON format and give the option to ignore GeoJSON errors.

For the full list of features, bug fixes and changes see the release notes on Github.

Happy mapping!

Opensnowmap style reload

Posted by yvecai on 12 November 2018 in English (English)

I've figured out recently that base map (topo) renders underground water pipes like plain rivers. It will need a database reload to fix this. Certainly I can correct other glitches at the same time, so have you spotted or can you find something else really wrong with this style? I'm mainly interested in mountainous places, of course, don't expect fixes in Manhattan subway lines ;-) The style is derived from OSM-bright. Thanks in advance, Yves

So how does the Facebook's AI Assisted Road Import Process work?

Posted by Jeff Underwood on 12 November 2018 in English (English)

So how does the Facebook's AI Assisted Road Import Process work?

Although the team has shared the process in depth at various conferences and discussion post and the wiki, we have gotten feedback that we could clear up some of the processes by providing more details. So here it is.

At Facebook, we use our ML (machine learned) data as a starting point but then completely re-edit, fill in the gaps, and correct errors with human editing. Machine learning can do amazing things, but even the best predicted area will always have issues that need a human to fix. An untouched ML file will often have disconnected ways, gaps in the network, road type inconsistencies, and geometry issues. The job of our human editors is to use this ML data as a base and build fully fleshed out, high quality data.

The Machine Learned XML file

This is the base file we work with. Our engineers take a snapshot of OSM data at the time of XML creation. They then merge our predicted roads onto this OSM data to produce the Machine XML file. From this starting point, the editor will cleanup and expand upon the ML data. A limitation that will be immediately apparent to some, is that by necessity, our ML data is merged with a snapshot rather than live OSM. This means that if we take too long to map it, the data could gain conflicts or someone could map out our predicted area. Luckily, our FB iD has some features that reduce the impact of these problems, which I will go into later on below. image_1 A typical Machine file. There are some breaks in generated roads and lints in pink.

Creating a Machine File image_21 A snapshot of OSM data is taken. Here you can see the town has been mostly digitized but many roads to the South are missing.

image_20 Generate a road prediction for the area. All the roads are predicted, even those that exist in OSM already.

image_22 Conflate the machine learned data with live OSM. Roads that already exist will be dropped from the ML output.

image_19 Final Machine File result. predicted roads that do not exist in OSM already are created. Predictions outside of the task bounds are included in a different XML.


Fresh out of the oven, our ML XMLs will typically contain several automatically applied validation checks that must be resolved and removed before our version of iD will even allow the file to uploaded. This sort of automated error flagging is called linting in software development.

Let's go into excruciating detail!

lint_disconnected When a road or cluster of roads does not connect to the greater road network they will get tagged with this lint. Once one of these roads is connected to the network, the tag is automatically removed from all the ways. Our policy is to either connect or delete as we don't want to create a bunch of roads divorced from the rest of the map.

lint_disconnected A typical lint_disconnected

lint_connectExtend This lint is essentially the "Way end node near other highway" check in JOSM. If one of our generated roads ends near another highway the machine will generate this to let our editors know that a connection might be possible here. These missed connections are often from obscuring trees or buildings and are typically confirmable with alternate imagery. Of course, some times the lack of connection is appropriate and in these instances, the way is evaluated and the tag just deleted.

lint_connectextend A typical lint_connectExtend

lint_crossWaterway To speed up the editing process, the machine file will automatically split and add a bridge tag when one of our roads crosses a waterway. This lint tag prompts the editor to first check the validity of the water feature as many are poorly digitized or difficult to see in satellite, then to adjust the automatically created bridge segment to the actual size of the bridge in imagery.

lint_crosswaterway a typical lint_crossWaterway

SplitPoints and lint_autoconnects When the ML data is being gridded up into tasks, generated roads that travel outside the bounds of a task are automatically split at a node and a tag is applied to tell the editor not to move this particular point. When it comes time to publish the data, if the other half of the split point road has already been uploaded in the neighbor task, our iD will automatically load the adjacent road and connect the two halves of the road together. When this happens, a lint_autoconnect tag is applied which cues the editor to check the connection for correctness and the highway types for consistency.

image_2 The red points at the end of the streets are SplitPoints. Our roads should automatically connect between tasks where these are present.

lint_autoconnect Example of an autoconnect. Notice that the adjoining road is also one of ours.


Our engineers have created a more advanced version of iD that has been fully customized for our purposes. The general design philosophy was to add some of the great features JOSM has while retaining the simplicity of iD.

image_3 FB iD

Load Live Data

Despite our XMLs being based on OSM data from the date we generated them, our iD has a feature to automatically pull the latest OSM data and update any preexisting road in the task area. Using this, we avoid experiencing almost all conflicts as our data is fresh each time we open our task area. If any duplicates pop up, like when a road we predicted has been digitized by someone else, these will be loaded and typically caught by our validator with a crossing ways warning.

image_4 The loading live data dialogue


Our version of iD has a number of handy enhancements built in to make it a much more powerful tool than the official version. Most useful to the community at large is our built in validator. This has many of the same checks that JOSM uses, such as overlapping ways and duplicate nodes, and helps prevent errors or poor quality data from ever reaching the live map. Like JOSM, we show a list of validation checks categorized into errors and warnings with errors blocking data upload until they are resolved. Our lint checks are also picked up by this validator as errors and also will also block submission.

image_5 Users can select and cycle through the errors using the arrow buttons. The way involved is highlighted and the error type is displayed in the corner


In our iD we display all of our ML roads in green, or pink if there is a lint tag. We restyled most road types from default iD to make them distinct in various ways since color alone was no longer an option.

image_6 The style sheet for ML data.

image_7 The style sheet for pre existing data.

Additionally, we developed two style toggles to aid our editing process. The first will turn roads bright blue if they have been touched by editor. This helps the editor track their progress as they work the task.

g_key Example of “edited roads” style

The second will randomly color our roads in order to show ways that could be better merged or split. Affectionately known as rainbow roads.

rainbow_roads Example of random color or “rainbow roads“ styles.

Also in the realm of styling, we created a grid overlay to break the task down into smaller pieces to also aid in editing. This can be set in whatever size is most comfortable for the user or particular task.

grid Showcase of the various grid options

Our ML prediction layer is also available as a toggle-able overlay. This can be handy while reviewing to ensure that the editor did not trim out any data we consider high value. You might also notice that we can fully turn off the data layer, rather than just wireframes. Another really handy feature.

ml_layer Example showing the ML layer


Getting from the Machine file to data onto the map is a multistep process for us. Everything must go through three stages of editing before it makes it gets uploaded and afterward we do an additional round of cleanup. image_8 The workflow stages

Editing Workflow

An editor will typically start in a corner and work their way along a task, going through ML roads one by one. They will check the generated highway types for correctness and change as necessary, improve the geometry or connections of the way, and, of course, evaluate if the road is even worth keeping. Marginal tracks are often discarded due to low impact for the amount of work needed to complete them.

image_9 A task before editing

image_10 and after

As a team, we are very cautious when changing community data as people are understandably protective of their hard work. People on the ground will have more context than we ever could as well. In iD, we actually disable deleting or splitting preexisting roads completely. When we do have to make alterations, an editor will leave a lint_fixme explaining the needed fix, typically road type changes. The reviewer will then evaluate if the change is warranted and make it themselves.

image_11 Community road with a lint_fixme saying it should be upgraded to unclassified

Once the geometry, tagging, and visible lints are cleaned up, the editor will run through the errors and warning on the validation panel for anything they might have missed.

validation_panle A small lint_disconnected was missed in the initial editing but immediately obvious with the panel

Lastly, an editor will zoom out and take a look at the highway tagging structure. Does it look correct? Does it follow a logical hierarchy? Only once they are satisfied do they click save to FB backend and mark the task as done. At this point, no data has been added to the live map.

image_12 Marking done on our internal OSM tasking manager

Reviewing Workflow

Reviewers follow a very similar procedure to editors. They also work grid by grid and check all the work of the editor. Additionally, they will make any changes needed to pre existing data that the editor requested.

review_fixmes The editor requested this community road be upgraded to an unclassified. In this case, the reviewer agreed and made the change.

When they do find issues they drop a lint_review tag and leave a note detailing what is wrong. These can be for incorrect tagging, missed or incorrect connections, or any number of issues.

lint_review The geometry here is not satisfactory so the reviewer left a lint_review with the note improve geometry

If the reviewer is not satisfied with the quality of work, the task is sent back to the editor for additional editing.

image_13 Sending back in our internal OSM Tasking Manager

If everything looks good, then the task is approved and we're on to publishing.

image_14 Approving in our internal OSM Tasking Manager

Publishing Workflow

Once a task has been approved by a reviewer, it is ready to be published onto OSM. The publisher will go through and cleanup any remaining lint_fixmes and make note of what needs fixing in JOSM after submission. They then click "Publish to OSM", add a changeset comment with our hashtag "#nsroadimport #thailand" and a comment saying what types of roads have been added and noting if any pre existing data has been altered.

image_15 a typical changeset comment

Our engineers have built a more robust conflict handler into iD so when conflicts do arise we can handle them in a painless manner. Rather than simply having to choose between my version or theirs we have the option to keep both sets of edits and intelligently merge the changes.

image_16 The enhanced conflict screen. Keep both is almost always the best choice.

Post-submission Cleanup

After uploading the ML data in iD, the publisher will then open the live OSM data in JOSM to do a final validation check and cleanup the borders of a task area. This part happens in JOSM since it has more robust validation tools than even our FB iD and we want to catch everything we can. We make an effort to combine our ways along task edges and to add consistency to our road tagging. Additionally, if there was any further work that had to be done to preexisting data, such as splitting a community road, we do it during this step.

image_17 A task opened in JOSM. We have a custom map paint style that looks similar to our iD. In addition to the data we overlay the project grid on top so that task bounds are clearly defined.

cleanup Showing the before and after in a typical task in JOSM. Notice the yellow intersections disappearing as roads along the border get merged. In the Southeast corner, two roads are extended to complete them.

Full Project Check

After a project is fully uploaded, we do a final cleanup of the submitted data. We load up an entire project grid in JOSM then download the data in the area. This is very similar to the previous JOSM cleanup step but at a grander scale. Some road type decisions are much easier to make once an entire area is present so this is an important step in making our data cohesive and correct. Again, we check task borders for any connections that need to be merged or were missed and run validation on the entire area.

image_19 An entire project loaded up in JOSM

Rinse and Repeat a Few Thousand Times

And that's how we do it. I hope this helps to make our process clearer. Please feel free to reach out if you want anything further clarified. We're happy to share :)

Glossary of terms

  • Machine learning (ML): a field of computer science that uses statistical techniques to give computer systems the ability to "learn" (e.g., progressively improve performance on a specific task) with data, without being explicitly programmed. For our purposes, this means teaching a computer to recognize roads from satellite imagery.
  • ML prediction: This is the output of our machine learning. In its raw form its a black and white image showing where the machine thinks roads exist. Our engineers run scripts to process this and turn it into our Machine XML files.
  • ML roads: OSM roads created from the ML prediction. AKA predicted roads
  • Linting: The process of running a program that will analyse code for potential errors AKA engineering speak for validation
  • XML: The file format OSM data is stored in. Often times saved with the .OSM extension though.
  • Machine Learned (ML) XML: a snapshot of OSM data that we merge our ML predicted roads with
  • JOSM: An advanced OpenStreetMap editing application that we use for validation.
  • FB iD: More accessible OpenStreetMap editing tool (that we have customized and use primarily).
  • OSM Tasking Manager: a tool for gridding out areas for mapping. Our internal version is based on OSMTM 2 while the current HOT OSMTM is the newer version 3
  • Community data: OSM data created by someone outside of Facebook .

Helpful links

Import discussion

Import Wiki

Thailand Discussions

Indonesia Collaboration with Local OSM Community and HOT

Association Voile et Nautisme 04

Posted by Philippe Allenet on 12 November 2018 in French (Français)

Club de Voile et d'aviron à Sainte Croix du Verdon Latitude : 43.757906 | Longitude : 6.150315

Location: Pourettes-Est, Sainte-Croix-du-Verdon, Digne-les-Bains, Alpes-de-Haute-Provence, Provence-Alpes-Côte d'Azur, France métropolitaine, 04500, France

OAuth auch für Talk

Posted by addresshistory*org on 12 November 2018 in German (Deutsch)

Aus gegebenen Anlass rege ich an, dass sich die talk Plattform in die Umgebung einfügen sollte.


Переведите вики на русский язык перестаньте позорить проект !!!

Posted by Sowa1980 on 12 November 2018 in Russian (Русский)

Предложение для всего русскоязычного сообщества посвятить весь декабрь переводу вики Цель не оставить не переведенной ни одной статьи на русский язык, можно, пользоваться автоматическим переводом, в любом случае это польза для новичков при русскоязычном поиске по вике, после гуры и знающие язык, могут до перевести эти страницы. Да и нагрузку на чат ( снизится, и вопросов, а как замапить станет меньше))

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

Прошу всех не ленится и присоединиться. Кто присоединиться молодец, кто нет протухший огурец)) Иначе осм так и будет дальше слыть как сборище демагогов, которым все лень.

Хватит позорить проект, ребята, зайдя на вике ни одной статьи почти нет переведенной и верной первоисточнику, новичкам и людям пришедшим в этот проект в первой вообще трудно, что-то понять. Все что есть в проекте толком не работает или работает через пень колоду, Вам не стыдно ?, что на какую ссылку не ткни мёртвый ресурс, и лишь бла, бла в чате? Как вы хотите развивать проект и какое к нему будет отношение, когда пришедший в первые в проект человек видит все это? И главное, что он не видит сплочённости и решимости сделать, что-то лучше! Заканчивайте с вашими кричалками об OSM и аниме.

Также хотелось бы, что бы была налажена работа по:

  1. переводить еженедельник OSM
  2. улучшать сайт По сайту хотелось бы видеть голосование за те или иные предложения OSM сообщества. ( это пока можно считать первоочередной задачей, но ни как не умаляю других задач.
  3. Интеграцию на сайте, сделать его основным ресурсом, то есть центром всего и вся OCM, где будет собрано все в единую структуру, Голосование, новости проекта, чат, созданы рабочие команды команды работающие в том или ином направление. Отправной точкой должно служить все в OSM есть и все работает, только так и ни как иначе.
  4. Улучшать заготовки и делать их.
  5. И т.д ( работы и фронт работы огромен!!!) - Выбирай что тебе близко и присоединяйся 😃 или просто рисуй карты и получай удовольствие 😃 .

Карты от OSM под различные навигаторы ссылки смотрите ниже:

Posted by Sowa1980 on 12 November 2018 in Russian (Русский)
  1. navitel и 7 дорог -,,,
  2. osmand - Скачать обновление карты можно из самой программы.
  3. Ситигид -
  4. Garmin -
  5. ПРОГОРОД - Скачать обновление карты можно из самой программы или с официального сайта
  8. ГисРусса - pocketgis - Скачать обновление карты с официального сайта

Revisão Rodovias sem Ref no Tocantins

Posted by erickdeoliveiraleal on 12 November 2018 in Brazilian Portuguese (Português do Brasil)

Acredito que tenha conseguido adicionar 90% ou mais de refs nas rodovias do Tocantins. Utilizando a camada IBGE trechos de rodovias e mapa rodoviário <3