R Refrigeration 📞 𝟗𝟑𝟐𝟏𝟑𝟖𝟕𝟓𝟖𝟑 Shop 32, Laxmi Market, Sector 16, Koparkhairane, Navi Mumbai 400709, #rrefrigeration #RA #Follow #Trending #navimumbai #navimumbaikar #Technician_Raja #trendingreels

Геоинформационный портал Калужской области - набор электронных картографических сервисов, обеспечивающих открытый доступ заинтересованным пользователям к массиву пространственных данных нашего региона посредством глобальной сети Интернет. Сссылка

Реестр парковок г. Калуги

Реестр сведений о парковках общего пользования, расположенных на территории муниципального образования “Город Калуга”.

Ссылка

Комплексная схема организации дорожного движения города Калуги

Содержит перечень дорог с их категорийностью и другими характеристиками (см. файл Отчет КСОДД).

Ссылка

АО “УКОН”

Информация о городских ярмарках и банях.

Ссылка

This blog post is part of a series of blog posts about the new OSM file format “OMA”. This is the fifth post. At the end of the article you’ll find links to the other blog entries.

 

When relations where introduced (in 2008, if I remember correctly) I was a big fan of them. They sounded great and promising. Meanwhile I think, it was a mistake to add relations, and if I where to decide I would probably remove them from OSM and replace them with something better.

Let’s have a closer look: Nodes and ways (and areas) are simple: A geometry with some properties. Relations do not share this simplicity. They share the properties, but they do not have their own geometry. Instead, they contain references to some elements. This makes things complicated.

I could write several articles about relations and why I think they are a bad idea, but this article is about relations in Oma files, so I’ll leave it at that for now.

 

Multipolygons

Instead, I’m going to take a closer look at what is currently done with relations. According to taginfo, more than half of all relations are multipolygons, that is, a collection of areas. Since we’ve already got areas in Oma files, this is easy to handle: All multipolygons are converted to one or more areas.

You may be wondering why I didn’t add a multipolygon (or multiarea) data type. Well, in the case of nodes and ways, OSM does not have a multi variant. So I do not see why we should treat areas differently. (Please note that areas in Oma files can contain holes, while in OSM the ways that form areas cannot.) All in all: For me it is much more straight forward to omit multi-variations everywhere.

 

Restrictions

Coming back to taginfo, the second place are restrictions. They make up about 16% of all relations. Typically, restrictions contain two ways (called from and to) connected by one or more elements (called via). Restrictions tell users whether or not they can continue their journey in a particular direction.

After thinking for a long time about how to fit them into Oma files, I realised, that the from and to ways are not completely needed. Only the last segment of the from element is used and only the first segment of the to element is used. Once I realised this, it’s obvious, that restrictions are just ways, with the first and last segments playing a special role. And so I decided to convert restrictions to ways.¹

 

Routes

Next on the taginfo list are routes. They are difficult to convert, and for a long time I didn’t know what to do with them. Unlike multipolygons and restrictions, they are not just a geometric replacement for another type: In the case of routes, the tags of the members can be important. In other words: They are real reference types.

Until now, the Oma file format was a reference-free format. I reluctantly accepted that I had to add some references here. In OSM files the references point from the relation to the members. This is problematic in Oma files, because some elements have been split, so the IDs wouldn’t be unique any more. And anyway, IDs were not needed at all up to here.

So I turned the references around: For this type of relation, they now point from the members to the relation, or collection as I call it in Oma files.² This is better, because now only the collections need to have an id. This saves space and the ugliness is at the place, where the ugly elements are.

The drawback of this approach is obvious: when you’ve got a collection, you do not know the location of the members, so you need to search the whole file for them. To avoid this, I have added a slice description list to each collection. This list tells you, which slices contain the members of the collection and thus can speed up the search.

Development of this part is still ongoing. The current implementation of the converter does not compute this list, and so searching the whole file cannot be avoided at the moment. The problem is that calculating these lists is not easy and probably needs a fourth step in the converter. I hope to find the time to implement this in the near future.

 

Boundaries

On with the show: Next are the boundaries in taginfo. Boundaries are almost the same as multipolygons. The only difference is a few small additional elements, in most cases just the admin centre.

Once collections are set up, the solution here is simple: Convert all members that resemble multipolygons to areas and make a collection of them and all other elements.

 

Public Transport, Destination Signs and other Relations

There are two other types of relations left: public_transport and destination_sign. Public transport relations are quite new, and if I were to predict the future, I’d say they’re going to cause some trouble. However they are here and I have decided to treat them similar to routes as a collection.

Destination signs, on the other hand, are quite similar to restrictions, except that they can contain the location of the sign. So I created some ways from the restriction like members and made a collection out of them together with the sign position.

I didn’t look more closely at the other relations. They are not used much anyway. The converter converts them to collections.

See also

• A New File Format for OSM Data
• Using the Oma Library
• Getting Files in OMA File Format
• The OMA File Format

---

1. It’s possible for restrictions to contain more than one from or to ways. In this case more than one way is created in Oma files. ↩

2. Some months ago Netzwolf suggested this for OSM data. I don’t know if he invented it or someone else. ↩

مراعي ابل

مراعي حيوانات

مراعي

En el contexto de una clase de Cartografía Digital que estoy dictando en una institución de educación superior, les mostré OSM a mis alumnos para que sepan de este interesante proyecto que yo conocí el 2019. No me había interesado mapear hasta ahora que vi que falta mucha información y además que la existente contiene muchos errores.

طرق

سيارة قديمة

مياه امطار

تخييم

مياه امطار

مياه شرب

مياه

تخييم

مياه

عشب حيوانات

ارض جرداء

عشب