Recent diary entries
Terzo mapping party a Mozzecane! Contribuiamo tutti assieme a mappare Mozzecane con OpenStreetMap. Ci troviamo sabato 12 settembre 2015 alle 9.00 davanti alla biblioteca comunale, l’associazione LinuxLudus darà il supporto per il mapping party.
Cosa abbiamo già fatto? Nelle scorse edizioni abbiamo inserito i dati di tutti negozi e i numeri civici a est della via principale. In questa edizione inseriamo numeri civici e altri dettagli non ancora presenti su OpenStreetMap a ovest della via principale.
Perché questo lavoro? La mappa è usata dal comune per migliorare i servizi al cittadino e con i mapping party la rendiamo sempre più dettagliata per avere un servizio di qualità! Se vuoi unirti a noi compila il form di iscrizione che trovi a questo link: https://docs.google.com/forms/d/1XhGniHvXoZ8vnuhKtV-ESxaTh6JZBgZLw9Oyxu7j_wQ/viewform
Cosa serve portare? Niente! Tutto il materiale e le informazioni che servono ti saranno dati dall’organizzazione. Che aspetti? Iscriviti! Ci vediamo presto
While looking for missing paths to trace using the Strava Routing Errors tool, noticed the heatmap picking up a lot of activity going into one particular office.
On a closer look, turned out to be a tech company by the name Linear Technology (roof logo!).
Here's a thank you map for all those awesome bikers from there contributing to the open map. Keep biking!
Mysore Palace ( Kannada: ಮೈಸೂರು ಅರಮನೆ ) also called as Amba Vilas Palace located in the city Mysuru, Karnataka, India.
The whole building is marked as
building = yes on top of it everything is
building:part = yes. Texturing is another important thing in 3D development. Used Hexadecimal colour codes to building facade and roofs.
Kendzi3d is a useful plugin for JOSM for 3D mapping. It renders the building parts immediately as soon you change the
building:colour... etc tags with out uploading the data to the OSM.
Screen shots from F4 Map
ಅರಮನೆಯ ಒಂದು ನೋಟ ನೋಡಲು ಇಲ್ಲಿ ಕ್ಲಿಕ್ ಮಾಡಿ. 👉 F4 Map link is here
Happy mapping 😀🌎
Je suis mappeur plus ou moins régulier autour de Rennes et dans le sud mayenne. Je me concentre beaucoup autour des cours d'eau bretons ces temps-ci.
Hoppla. Diese Woche bin in der Wochennotiz zu finden, nämlich mit meinem Kommentar (w-j-s) hier: http://blog.wikimedia.de/2015/05/30/visualizing-history-with-automated-event-maps/#comment-15128 (und das Argument fand Gehör)...
Mapping las Margaritas can be very time consuming so I have moved back to the Backcountry of Chiapas. I estimate that I have mapped 95% of the roads in the lower right corner, not counting the tracks which are relatively unimportant and extremely numerous in the area. What I am calling the lower right corner of Chiapas is basically the flat lands that are to the south east of Parque Natural Montes Azules within Chiapas. I estimate that within the week I will finish mapping all major roads, and residential roads within this lower right corner of Chiapas. I have begun adding names to the towns using what I find in Google Maps, It seems to be trust worthy, as on more than one occasion the names have been supported by signage within Google Street-view. I also hope to finish adding all the names of these small towns in the lower right corner within the week.
So what is next?
I have already begun expanding into Guatemala. So far I have constrained myself to the obvious natural borders with the area, Río Chixoy(OSM)/Río Negro(Google Maps) has been my main constraint to the south Mapping here is practically finished with lower right corner Chiapas. My main constraint to the east has been Río Salinas(OSM)/Río Negro(Google Maps) to the East. This is actually the same river as Río Chixoy(OSM)/Río Negro(Google Maps) and I will need to do research to find the correct name. Río Salinas(OSM)/Río Negro(Google Maps) is the eastern border of Chiapas so for the most part this is finished as well.
The plan of action right now, is to see where the edits take me. But the plan is that I will continue to the north on MEX 301 and finish off the last bits of lower right corner to the north of Benemérito de las Américas, and finish the major highway editing within lower right corner!!! =D After that the I will probably move to 3 major areas. First East of Lower Right Corner in northern Guatemala where similar to Lower Right Corner's condition a year ago there is virtually no basic highway data. A name personal name is pending for this area, but I will likely just keep calling it East of Lower Right Corner This area should go relatively quickly as the roads main roads are very strait, and with no guarantee on the accuracy of the of the satellite imagery as far as offset, accuracy of every 2˚ bend is not critical. The main constraining factor to this area is imagery as there is no imagery to east.
After this The next obvious place to map is the River Lands which is what i call the area to the west of Lower Right Corner in Chiapas. I plan to expand to the north and west in this area, until eventually mapping everything east of Las Margaritas. I am also working on adding basic highway data in the areas to the south of the River Lands in Guatemala. The main constraining factor here is again no satellite data to the south. The imagery is also somewhat dated as there has been recent construction of a new major highway in the area, this is the limiting factor tow the west in this area of Guatemala. in the River Lands only so much mapping can be done to the west, as the quality of the satellite imagery degrades, and there is a large number of clouds making mapping difficult. This means that once basic expansion has been done to the south and west, the obvious place to expand to is to the north where the satellite imagery is of relatively high quality.
This is all just a basic plan, and subject to change, but I have found in the past that working in areas where there is a clear direction to expand in is helpful in preventing exhaustion as when there are no constraints, such as in the campo areas of Puebla, it is easy to become overwhelmed by the sheer amount of area to be mapped.
Well that is mostly it for now I will update as time goes on.
Ogni giorno nuovi possibili utilizzatori di OSM aggiungono note sulla mappa per segnalare errori o, involontariamente, inserire note poco utili al progetto (es. usarle com promemoria personale o segnalare eventi). Spesso può risultare cruciale rispondere ad esse prima che l'utente perda interesse ad aggiungere nuove informazioni alla sua segnalazione.
Tramite le API di OSM è possibile creare un feed RSS che ci segnali le ultime X note aperte in ordine di data di creazione, dalla più nuova a quella più vecchia. La stringa che utilizzo come segnalibro live su Firefox è la seguente:
*notes.rss indica il formato di output (in questo caso RSS). È possibile dare l'output anche come XML, json o gpx, sostituendo dopo il punto il rispettivo formato desiderato.
*bbox=[longitudine_minima,latitudine_minima,longitudine_massima,latitudine_massima] indica il Bounding Box su cui verrà effettuata la query. In questo caso corrisponde alla regione Veneto.
*limit=50 indica le ultime 50 note
*closed=0 indica solo le note che non sono ancora chiuse.
Aprendo il link nella barra degli indirizzi di Firefox sarà possibile aggiungerlo come "segnalibro live" alla "barra dei segnalibri".
Per ulteriori informazioni vi rimando alla pagina wiki Notes
Daten zu erfassen ist (relativ) einfach. Sie aktuell zu halten ist weitaus schwieriger.
Wenn man auf einer Karte etwas nicht sieht, weiß man, hier fehlt was. Dann kann man dort hinfahren und das Fehlende mappen. Wenn die Karte vollständig aussieht, merkt keiner so schnell, wenn was fehlt. Große Bauprojekte beobachten viele OSMler gespannt und sind auf eifrig dabei, sie zeitnah zu erfassen. Wenn irgendwo ein Einfamilienhaus abgerissen und neugebaut wird, merkt das nicht sofort ein Mapper, es sei denn er kommt dort regelmäßig vorbei. Wenn ein Restaurant schließt oder ein Briefkasten neue Leerungszeiten hat, ist das nicht auf die Schnelle zu erkennen und auch nicht mit OSM abzugleichen. Man muß schon direkt in die OSM-Rohdaten schauen und abgleichen.
Eine Auswertung  von Jan (User Lübeck) hat mich ein wenig erschreckt. Dort hat er alle Telefonzellen abgefragt. Und wenn man die Realität mit der Karte vergleicht, wird man feststellen, daß sehr viele Telefonzellen mittlerweile abgebaut sind, in OSM aber noch existieren. Deswegen haben wir uns vom Lübecker Stammtisch schon vor längerer Zeit das Tag 'lastcheck' in Benutzung, welches angibt, wann das Objekt zuletzt von einem Mapper überprüft wurde. Ich war anfänglich auch nicht begeistert und fand es nicht sinnvoll. Die oben genannte Auswertung zeigt aber sehr schön, wie sich die Aktualität eines OSM-Objektes so leicht visualisieren läßt. Alle grünen Punkte sind Telefonzellen, die im letzten Jahr überprüft wurden. Rote Punkte haben kein lastcheck. Die anderen Farben bedeuten, daß der POI in den anderen Jahren zuletzt gecheckt wurde.
Deshalb setze ich jetzt auch immer 'lastcheck' ein. lastcheck wird in Form YYYY-MM-DD gemappt. Also z.B. lastcheck=2015-08-20
Manche sagen, daß solche Metadaten nicht in die OSM-Datenbank gehören. Wohin dann? Es sind ja nicht nur Infos für mich, es sind Infos für jeden Mapper. Sollte man deswegen eine zweite Datenbank aufmachen? Ich denke nicht. Wir haben doch sowieso schon immer solche Metadaten drin. So hängt zum Beispiel an jedem Objekt der Username, die Uhrzeit und das Changeset. Seit eh und je benutzen wir 'FIXME' und 'note', um anderen Mappern Infos zu hinterlassen. lastcheck ist da nichts anderes.
Das Änderungsdatum eines Objektes ist da nicht unbedingt aussagekräftig. Das Objekt kann schon seit vielen Jahren korrekt gemappt worden sein und ist immer noch aktuell. Oder wenn ein Mapper einen veralteten POI etwas verschiebt, hat dieser nun ein aktuelles Änderungsdatum.
Gerade im Bereich der POIs findet sehr viel Veränderung statt. Da ist es schwer, diese aktuell zu halten. lastcheck gibt einem einen Hinweis, wo man vielleicht mal genauer hinsehen sollte. Denn damit OpenStreetMap attraktiv bleibt, brauchen wir aktuelle Daten von POIs.
If you're subscribed to the HOT mailing list you've seen a recent invitation to help develop a funding application for the Knight Prototype Fund, coordinated by Russ and Blake. The intention was to discuss project proposals that may be suitable for this grant. The initial IRC meeting then developed into a larger conversation around current HOT needs for better tools: the resulting Google Doc with meeting notes lists six project ideas.
The strongest candidate was a proposal to develop a HOT/OSM tool to support Quality Assurance (QA). You can read some details in the grant proposal writeup, however it's a fairly high-level text. Informed by our discussion I also developed a draft specification, with a more detailed list of considerations and potential features.
I'm posting this draft specification here to get your feedback, and to hopefully stimulate some debate about what a good QA support tool might look like. The proposal is a result of conversations with HOT practitioners, and based on my own use of HOT and OSM data. However there are likely many community members with further ideas, and some may even have worked on HOT QA initiatives. We would love to hear from you! In particular we would love to hear from validators, and from existing users of HOT data. What specific data quality concerns arise in practice?
(I should also state that I don't have a deep understanding of the Humanitarian Data Model -- there are likely some useful concepts in there that could be more emphasised in the spec.)
Our general ambition is to make HOT progress more visible. More specifically, the proposal aims to support our existing QA processes around HOT validation. Crucially it further aspires to provide a means of demonstrating HOT data quality to prospective users of the maps.
Aims of the proposed QA support tool:
- Impact analysis of HOT coordination efforts: to describe our outputs in ways that are meaningful to the HOT community, to prospective data users, and to a wider public.
- Evaluating fitness for specific purposes: to assess the quality of the data in relation to the specific concerns of data users.
- Integration support: to assess the structure of the data in relation to the Humanitarian Data Model (HDM).
The design of the QA support tool should be informed by the needs of existing users of HOT data: most importantly HOT activation partners, and requesting organisations with specific information needs. This also includes prospective users in aid organisations who still need to be convinced that the data can be useful.
It should also be informed by the needs and experiences of HOT validators: they are most well-informed about HOT data quality concerns, and they are likely going to be the most active users. The QA support tool should integrate well with HOT validator workflows, however it is not meant as a replacement for existing tools. I imagine its most useful function will be as a final check: a summary report of the outcomes of a particular mapping initiative.
The design could further consider the needs of other potential users of HOT data: people who want to report on current issues, or who as part of their work can make use of geospatial data. This includes local communities, local and international journalists, engaged citizens, and supporters of aid organisations.
What are their needs?
(This is a bit speculative. Please share your thoughts on this.)
"Which data sets are available?" Which regions are covered? What kind of information is captured?
"What is the quality of the data?" An assessment of map completeness (coverage), consistency (e.g. of annotations), and various measures of accuracy. An assessment of the age of the data, and of its provenance: which imagery sources were used to produce these maps?
"How can we access the data?"
"How can we integrate it with our information systems?" For example, how well does it map to the Humanitarian Data Model, or other standard data models?
The QA process: tests and reports
I. Basic report (derived from OSM edit history):
- How much data is there?
- How many people contributed?
- How old is the data?
II. Coordination report (derived from edit history and TM2 data):
- HOT project identifiers: links to the projects that produced this data
- Have contributions been reviewed (validated)? where? what changes were made?
III. Automated QA (basic validation):
- Untagged objects
- Overlapping objects
IV. Annotations report: which annotations are available?
- Geospatial information: road names, place names, ...
- Data provenance: description of imagery source
- Data management: review-related annotations (e.g. 'typhoon:reviewed')
V. Humanitarian data report (derived from OSM edit history, HDM):
- What map object types have been mapped? how many objects are there?
- E.g. "150 buildings, 15 hospitals, 3 helipads"
VI. "Fitness for purpose" reports: assessing the availability and completeness of data in relation to specific needs:
- Availability of building data needed for population density models
- Availability of road data for transport planning
- Availability of infrastructure data (hospitals, schools, helipads, ...) for aid coordination and logistics
Should a QA support tool also include its own workflows to address specific issues, or focus on descriptive reports as outlined here? Will our existing validator workflows remain sufficient as we grow?
Who should be doing QA work? How much of QA requires "expert" knowledge? Can we consider QA a general community activity that's open to all? E.g. by using guided workflows with good documentation. (This is also a discussion about HOT validation practices.)
I have not used iD much as I usually use Potlatch2 which I'm very happy with. I was interested in seeing how iD handled turn restrictions, the answer is very well. It works like this. Start iD, click on junction node. click on the "in Way" and the allowed out ways have a green indicator and the not allowed show red. You only have to click on one of the Reds or Greens to toggle or swap them, Excellent.
Last week I went over Tavelsjöberget three times, tracing and looking for points of interests for hikers. As I don't have a an ATV (nor a snowmobile during the winter) I didn't bother checking those routes. The picnic sites and toilets are still, afaik, available all year around for such activities as well.
I went by bus to one side of the mountain, to Sand bus stop C which is next to Tavelsjön. Nearby there is a café, beach, minigolf course and such there which of course attracts some tourists, so I figured I could map some of it. When walking from there to the mountain path's start, you pass an attraction (which is along Tavelsjön Runt, something I'll probably build a relation for some day) called "Sikta Tavelsjöodjuret". In English this translates to "Find the Tavelsjö monster" (see: local version of the Loch Ness monster). There's a small information board next to it, while the attraction itself is a metal pipe aimed at Tavelsjön, which shows the location "where the monster is most often sighted".
The walk I took was about 5km (not counting height differences) but as I didn't stay in any of the cabins there I had to walk about the same length further to get to my sleeping place. This was the "shortest and quickest" route, but I mainly wanted to get things like picnic sites and such properly marked. There are some reference data (such as the municipality's index numbers for the shelters etc.) that I still want to get - and of course I want to walk one of the longer paths to make sure they are correctly marked on the map as well.
The probably most popular and best equipped picnic site's coordinates is linked to this post, it's the "Tavelsjöberget" picnic site, relatively near the (small) mountain's peak. It has a toilet called "Ändamålet" (where "ända" means "butt" in Swedish and "mål" would here be interpreted as "finish line").
Right now I'm suffering a cold and my throat hurts when I swallow. Though I'm pretty sure this was due to meeting people who had suffered the same symptoms before I went out, rather than a result of the walk itself.
OpenStreetMap has many tags, inherited from natural language with blurred meaning and definitions, depending on each mapper's understanding of associated natural language term. Also, many tags are representing more than one property of an object, such as, say, type of flora, populating particular area and presence of management of this area. (Good example is natural=grassland and landuse=grass.)
In ideal case, any classification system should have only "atomic" properties instead of "molecular", where several real properties are linked. (Good example is recently introduced scheme with leaf_type and leaf_cycle - independent properties instead of linked ones.)
One of extremely widespread tags with both bad features is natural=wood.
It belongs to natural=* class, and it gives people an idea, that only natural habitats should be tagged with it. Therefore, we also have landuse=forest, which means the same kind of habitat, but more related to man made objects.
Actually, it creates really huge problem. First, lets try to explain what exactly we should map with it.
Both natural wood and any kind of planted forest are areas of vegetation, dominated by trees. But there is no clear definition (in OSM), what does it mean "dominated".
natural=wood should, supposedly, tells us, that area of vegetation forms "natural habitat". But there is no clear explanation, what does it mean "natural".
landuse=forest should, supposedly, tell us, that area of vegetation is managed, or planted, or forms artificial habitat, or trees there are non-native. There is no clear explanation, is there any difference between landuse=forest and landuse=plant_nursery - difference is only implied, because nursery should be only used to plant young trees for sale or for planting it somewhere else for forestry management purpose.
So many variants, so many assumptions and lots of guessing.
Currently, in British OSM community, there is a process of habitat=* tagging scheme discussion going on. Concepts and definitions there are mainly based on Joint Nature Conservation Committee works and publications, including Handbook for Phase 1 Habitat Survey. I like this approach, but there is a problem: ecologists usually have different goals for their projects than OSM community has. They can use plain (single dimension) classifications with all existing variants, represented by compound classes.
This approach has positive features: it's impossible to classify any object with non-existent set of properties, and it's also impossible to classify anything incompletely, because each class has full set of required properties and its values. But in OSM it doesn't make any sense: mappers are non-professionals, and often they can't evaluate all required features to use compound classes. That's why multi-dimensional classification with no mandatory properties makes much more sense in OSM.
Multi-dimensional classification means that you can have any set of independently determined properties. For example, tagging scheme can have color and material properties. It means, we can tag only color, only material or both. We also can add third property (say, shape) to scheme completely independently. Single-dimension scheme will require total revision in this case, because adding another property will require making completely new classes.
Like, originally we had classes: "red_steel", "green_steel", "red_wood", "green_wood", Adding shape to single dimension classification will make it look like: "red_steel_round", "green_steel_round", "red_wood_round", "green_wood_round", "red_steel_square", "green_steel_square", "red_wood_square", "green_wood_square".
Looks extensive, right? So, multi-dimensional classification with independent properties is definitely more suitable for OSM. Then, lets try to establish basic properties for different types of tree vegetation, that will allow us to map almost everything we want without implications and assumptions.
First, we need fundamental tag to show, that "here are trees". Trees in general, nothing more. I believe, that natural=wood can probably work for it. Its meaning is currently blurred enough to use it like very broad thing.
What to map with this tag? Answer is simple: any area, where trees grow, regardless of anything. Yes, if trees are sparse enough to see them independently, you can try mapping them as independent trees with natural=tree. But even if you can, it doesn't mean you have to.
Ecologists and forestry management using canopy coverage as a criterion for classifying any area as "forest". But I think, for our purposes we can have certain scale of percentage ranges, for example:
- 0..25% of coverage - single trees, not recommended to tag as wood, recommended to tag single trees
- 25..50% of coverage - sparse wood
- 50..100% of coverage - wood
These values (single, sparse, normal) can be assigned to density key.
It's pretty easy to use these ranges, because if canopies covering a bit less than a half of territory, it's sparse, if more - normal wood.
Origin of wooded vegetation area can be tagged (if we know it), and it's pretty obvious, which values to use for this property:
But it only a kind of historical reference information, because 100 years old plantation of native trees is currently unlikely looks differently from completely natural forest, even in aspect of rows.
Therefore, we need something for current habitat state. It's only about how it looks and how similar is it to reference natural habitat. Based on ecological classifications and practical experience, we can define values for this key as:
- natural (which means similar to natural)
- semi-natural (which means, this area has significant traces of planting, cleanup, removal of dead branches, or, otherwise, being artificially planted, it has traces of succession, growth of new young trees and scrub)
- artificial (which means, it looks completely or almost completely different from natural habitat typical for this area).
These definitions are just a framework, but it explains the idea.
Management is another obvious property, describing the situation, but it could be tricky to find right values for this key, because management can consist of very different works. Therefore, I suggest using general tag like managed=yes in case if it's managed and making separate scheme (considering namespace usage) for types of management, such as cleanup, fire protection, pest control and so on.
Obviously, these framework keys and values are only an example, because correct tagging scheme should be discussed and tested on different real cases. Also, definitions for values should be given in clear manner to avoid any contradictions, broadening of usage and so on. But as a framework, it gives good example of classification, based on independent "atomic" properties.
For sure, it doesn't solve certain problems completely. Like, it doesn't help to filter out tree groups within city limit (which should be done using spatial functions of SQL extensions). But it is potentially able to solve all controversy of real situations, like proper and simple description of difference between city park vegetation and wild forest vegetation.
Trying to get involved in OSM in BD. Have used open source maps and tools a lot and wanted to really help in my hometown where I constantly find data lacking especially geo data.
Mon inscription et mes premiers pas dans la mise à jour des cartes.
Vou usar este post para documentar notas no mapa que usei ou notas interessantes.
Sítio Sanches https://www.openstreetmap.org/note/416187
Antigo Caminho, provavelmente usado durante o período colonial http://www.openstreetmap.org/note/402413
I have just an idea popping up that I want to share. In the city I live, there is a yearly big event. I think OSM is particulary suited to let the organisers display the map of the event (walking paths, small shops, parking) on OSM.
This would enable them to communicate effectively, to the partners, and to the general public using OSM.
Sometimes I have the impression that people blindly "fix" some problems in OSM. For example, I saw this:
One user traced the links without any
oneway tag and another user just inserted
oneway=yes to them. His changeset even says "Fixing motorway_link without oneway"...
If we ignore some not properly traced parts and a missing circular road on top, how could somebody fix them and not see that there are 3 motorway links with the wrong direction?
Я достаточно давно занимаюсь добавлением в базу OSM всевозможных POI (points of interest - магазинов, кафе, паркоматов и т.п.). Всегда напрягало, что полноценное добавление объекта требует или ввода многочисленных тегов вручную, или поиска аналогичного объекта и "копирования" набора тегов из него. Логичным выходом стало создание набора заготовок наиболее распространенных сетевых POI для редактора JOSM.
Итак, что же дает этот набор? После добавления его в настройках (меню Правка -> Настройки -> вкладка "Параметры проекции карты и отображения данных (третья сверху, со значком глобуса) -> подвкладка "Заготовки тегов" -> здесь нажимаем плюс и добавляем заранее сохраненный .xml-файл с набором заготовок, после чего перезапускаем JOSM) в меню "Заготовки тегов" появляется подпункт "POI Москва". Скачав необходимую область и поставив точку/полигон, выбираете нужный пункт - после чего выпадает менюшка, где нужно ввести данные, зависящие от конкретного супермаркета, ресторана (время работы, телефон, есть ли доступ для инвалидов и т.п.). Естественно, можно эти данные не вводить - тогда соответствующие теги не будут вводиться. Для удобства тут же помещена ссылка на сайт соответствующей сети магазинов/ресторанов, ведущая прямо на карту со списком этих заведений, откуда можно почерпнуть время работы, телефон.
После нажатия на кнопку "Применить заготовку", например, для "Крошки Картошки" точке присваивается следующий набор тегов:
amenity=fast_food brand=Крошка Картошка contact:phone=+7 666 6666666 contact:website=http://www.kartoshka.com cuisine=potato diet:vegetarian=no internet_acces=wlan internet_access:fee=no name:en=Kroshka Kartoshka name:ru=Крошка Картошка name=Крошка Картошка opening_hours=Mo-Su 08:00-23:00
amenity=public_service contact:phone=+7 666 6666666 name=МФЦ n-ского района official_name=Многофункциональный центр предоставления государственных и муниципальных услуг n-ского района opening_hours=Mo-Th 09:00-13:00,13:45-17:00; Fr 09:00-13:00,13:45-15:45
для платежного терминала QIWI:
amenity=payment_terminal brand=QIWI contact:phone=+7 800 7077759 contact:website=https://qiwi.com opening_hours=24/7 operator=КИВИ Банк (АО) payment:credit_cards=yes payment:debit_cards=yes payment:notes=yes ref=666
и т.п. - всего около 60 различных магазинов, банков, госорганов и т.п.
Архив с XML-файлом лежит по ссылке: https://www.dropbox.com/s/2zxes7p9u12bch5/shops_russia_moscow_region.zip?dl=0
Все названия выверены по сайтам, примерные часы работы повторяют наиболее часто встречающиеся для конкретных сетей. Ссылки на сайты - для Москвы/Московского региона. Аналогично, в списке - сети, характерные для Москвы.
Надеюсь, набор заготовок пригодится картографам. Жду обратной связи и предложений по добавлению других сетей (желательно с достаточно большим количеством точек).
Темой предыдущего недельного задания были пожарные гидранты.
Участие принял 1 человек, который отправил 1 пакет правок и добавил 5 гидрантов. Антирекорд, мда.
Где были добавлены гидранты, видно на карте:
Зато была улучшена украинская вики-статья http://wiki.openstreetmap.org/wiki/Uk:Tag:emergency=fire_hydrant. Хотя она, конечно, ещё нуждается в дополнении.
Сейчас: город Нежин.
Some tricks to map Streams in Mountain Area.
Mapping streams/rivers in mountain region could be very tricky. Sometimes it's difficult to differentiate between the valley and the peaks. Other times the imagery is covered with cloud, snow or not visible due to the shadow. Satellite Image showing parts of Gangotri National Park, India.
A few steps can be very helpful to deal with such problems.
Overview of the area
Before jumping into the task of mapping, take some time to have an overview of the whole area. This helps to have a better understanding of the region.
Switching between layers
Better to select the layer that best shows your interest features clearly. A better resolution imagery is not always the best one.
Using terrain layer
Basic knowledge contours could be very helpful while tracing rivers and streams, specially when hill shadow makes it difficult to see the riverbed. It helps to differentiate between peaks and valley. Also, you can easily find the way of the stream. Try using a combination of both terrain data and satellite imagery, works best.
Bottom to top approach
Water always flows from higher ground to lower(into the sea). Better to mark the big streams first, one which are major rivers and easily visible. Now try to upstream connecting small streams. Won't be a good thing to leave a stream going nowhere
What not to mark?
Mountain regions are filled with landslides and very small seasonal streams. It's very difficult to defferntiate between them. What is the correct way to map them?
waterway=stream & intermittent=yes?
What do you think?