Proposal talk:Region

Maritime

If you refere this to boundary=maritime than I suggest merging it with administrative, or as a different resources or similar scheme. If it referes to geographical names (such as North Sea/South Atlantic) than it should be merged with topographical as it shares similarities with mountain ranges (Himalaya, Rocky Mountains). --Skippern 08:29, 27 August 2009 (UTC)

I am not exactly sure what you mean be merge here. I am however absolutelz open to detailed discussion about what region_category values should be used. In fact I have included lot of them more as a proof of concept, than a proposal done after detailed investigation. So if the general notion is agreed on than there should surely be some stage of discussion about region_category values. I would however love to understand your proposal in more detail. --Jakubt 21:52, 28 August 2009 (UTC)

I am not sure what you meant with maritime. It might have several meanings, but the example you gave I would group it together with maintain ranges as a topological border. Splitting this with different region_category for mountain ranges, oceans, other large geological or topological areas is meaningless. Though maritime can have other meanings as well, most of which can be grouped with other topics, to make it clearer. All administrative regions should be grouped together wether they are on land or at sea, etc. --Skippern 11:14, 29 August 2009 (UTC)

I understand now, have added note to the proposal, see Relations/Proposed/Region#cite_note-4. --Jakubt 13:50, 3 September 2009 (UTC)

IS_IN

I do not know if it will replace the is_in tag, but rather amend to it. It will surely be a more reliable and human readable structure than the existing is_in, and will be much easier to maintain than the is_in relation, though believe they can live together. Where I grew up, Gjemnes, Norway, I could say that my home was in Gjemnes electorial district, Gjemnes postal area, Gjemnes school district, and Gjemnes church district, all with its own borders, and this type of relation will allow me to maintain this without the need of editing every single node, way and relation in the area. (I lived 2km from the geographical Gjemnes, but all of them are a part of the municipal of Gjemnes, which have its administrative center at Batnfjordsora, I also hear roumors that Gjemnes school district doesn't exist anymore...) --Skippern 08:29, 27 August 2009 (UTC)

You are right, it is by no mean ment as replacement of is_in tag. However I agree with you, that if it is accepted, than it greatly simplifies editing process, and let you replace lots and lots of individual edits of nodes, paths and areas by one big one. Than is_in can be used on these (IMHO very rare) cases, where the Relation:region does not work well ... BTW I wonder what would be a typical example of such a case. In fact there is possibility that Relatio:region may even greatly muliply usage and usefulness of is_in tag, because - if the community agrees on it - it is possible to autogenerate many is_in tags from just one Relation:region. What do you think? --Jakubt 22:01, 28 August 2009 (UTC)

Religion

For regional devision of various religions, I suggest that they all are identified by the same regional_class (religion), but are separately identified with religion=* and denomination=* just as amenity=place_of_worship - they are related --Skippern 08:29, 27 August 2009 (UTC)

That sounds like a very good idea. In fact this can be generalized, because proposed Relation:region builds on many already used tags and relations and have analogical use with even more of them. I am adding - related tags and relations to the proposal, thanks for the idea. --Jakubt 22:03, 28 August 2009 (UTC)

Geometry construction

You are proposing to construct a relation that represent areas but you move the geometry in only one member, which will, in complex cases (given that you want to create seas, admin regions, that will probably be "most cases") be another relation. Why that ? isn't it a bit simpler to allow building the "advanced multipolygon schema" directly in this relation ? (ie allowing multiple ways with role and possibly other relations) ? (it is not critiscism, it's a curiosity) sletuffe 20:15, 29 August 2009 (UTC)

This is very good question. Basicly there are several reasons for this. 1) If boubdary is just a reference for boudary, than the boudary object can be reused easily. 2) I think that if I "enrich" the data-structure with many other informations regarding boundary shape, than the proposition would be too "fat". I rather reuse existing datastructures. Also if in the future something in specificatoin of multipolygon or other boundary types changes, this proposition will be "updated" automatically. 3) How would you do that? take only some part of, say, multipoligon, but throuw out others? what would be the type of the relation? Region? Multipolygon? Both? (BTW is this even possible?) 4) I think that the "collection of pathes forming an complex area" should be separate datatype in osm, and if this is the case. than I would use it exactly like that. --Jakubt 23:15, 30 August 2009 (UTC)

Case 1) is it needed that the shape can be reused for different region ? isn't it better to put tags in the first relation ?

The solution of allowing any number of ways and relation members doesn't forbid from having only one super-relation member if that case is needed.

Case 2) wiki issue, of course copying Multipolygon#Advanced_multipolygons is a bad idea, but we could just give a link to it and say "you can enter way members with inner and outer role like explained in Multipolygon#Advanced_multipolygons" Adding relation members to create super-relation is not yet described anywhere, that could be a proposal to develop and create

Case 3) yes, and use type=region, saying it is the same shape construction as described in multipolygons.

Case 4) that would sure be cleaner, and it sounds much like a programmer's view. But I'd like to find the balance between, easy to tag and easy to use. sletuffe 13:52, 31 August 2009 (UTC)

covering too much (administrative case)

Also I find this "region" idea brilliant, I'm wondering if, for some cases of you region_category, it is not "too much" for few benefit over the well established and rather not so badly working administrative cases.

The way Relation:boundary is used and constructed is almost the same as this region solution having the advantage of being allready in used and well present in mind of those who use it, with the drawback of losing a form of "normalisation" which this region proposition solves.

What exactly you call normalisation? Just wonder. --Jakubt 22:51, 30 August 2009 (UTC)

Sorry I wasn't clear about that. This is a more general thought than your region proposal. It joins all debate on talk list about data object in osm and the way we store it. In osm, points are stored as node, simple line of nodes as way, simple area as closing way, but all complex case (holes, reuse of group of way, ...) are handeled with the relation system, and this is not really clear. Frederick Ramm tried to create a general "type=multipolygon" to cover all complex cases that forms areas, but there were side proposals that are constructed almost the same but with a different type=*. type=boundary comes to mind, and so does type=region. When I read your region proposal, it looks like a proposition that could deal with any area types. Thus a "normalisation" to create area "regions" of any kind. sletuffe 14:24, 31 August 2009 (UTC)

In the advantages, you say it It gives hierarchy of places and areas, well the admin_level from 1 to 10 do it as well. The automatic guessing number of levels is possible as well because you echange 2/4/6/7/8 by "state / county / township / city / village / province / prefecture". Numbers are not perfect, I admit, and leaving "holes" between 2 and 4, 4 and 6 was articial and not really extensible, but I find it a better chance to create a world wide (almost) compatible way to compare a 6 and a 6. Also usage of the data seams a little easier with number instead of hierarchy computation.

I do not fully understand all your arguments here sorry :-( What does it mean "better chance to create a world wide (almost) compatible way to compare a 6 and a 6". If you want to compare levels of two regions, than you simply have a look how deep in hierarchy of regions thay are and it gives you this magic number as well. I understand that for renderers it is easier just to read the number than have to compute the level itself. If it is really a problem (in terms of effectivity) I would suggest computer bot which would be crawlig the database and automatially precount these levels (or maybe serve as proxy for renderers for). --Jakubt 22:51, 30 August 2009 (UTC)

What I meant was, if you run a bot to compute the hierarchy from the lower level, if two countries have different number of level, then you will end with guessing the country boundaries is n°5 in france and maybe n°4 in Italy, your world map won't match. Unless you expressly say administrative=state, wich, in the end, is equivalent to say admin_level=2 (in the current shema) and (as least, it's what is understand) is replacing numbers by words. sletuffe 14:24, 31 August 2009 (UTC)

In regards with Relation:boundary I think that there are some problems thought. First of all Relation:boundary is probably used "almost" the same, but it surely is not designed as such. By looking on its definition and discussion around it you will see that there are very basic misunderstandings about "right" way to use it. Practice may differ, so I would not like to be in renderer's developers shoes :-) ... also tere is a unsolved dispute about boundary vs multipolygon with many different arguments, but neither of them separates boudary's geometrical shape from "semantic" information about the boundary. Imagine the most usual case, when same boundaries is shared between for example juridical district and administrative state - currently it is impossible to cover such cases other than copying the boundary, so if there is a change in on, that it should be transferred manually to other cases. What I like about Relation:region is that it only "relates" to its boundary, which can be multipolygon, or even boundary, or closed loop. Therefore you can easily reuse the boundary information. But this is only an example I think that principally it is good to separate the boundary's geometry from the rest of the information.

The boundary VS multipolygon problem is to my opinion only a problem of "word" : When I watch the tool osm2pgsql which convert relation to shape, the code to handle boundary is the same as the one to handle multipolygon, only does the word change and inner/outer is replaced by enclave/exclave. To my point of view, we should be using multipolygon only, and germany proved that it worked. type=boundary was maybe define as duplicate in the same time. Creating another type=region doesn't seams to solve the problem either (or there is something I missed)

Handling multipolygons and boundaries the same way in osm2pgsql is an obvious mistake, currently resulting in bad rendering of boundaries in mapnik. It's not just a change of words, because boundaries should be handled differently than mulipolygons. --Eimai 12:58, 6 September 2009 (UTC)

I'm sorry if I haven't been clear, but I was refering to so called "advanced multipolygons" not to the "basic" multipolygons. (ie those that are constructed the same way as the type=boundary relation, those that do no implies to have properties transfered to the member way, those that have their properties (tags) in the relation itself mostly resulting in untagged way members, unless needed) sletuffe 23:17, 11 September 2009 (UTC)

About copying the boundary, yes, for now it is the only crappy way to do it, that's why I started Relations/Proposed/boundary_segment to help with it. (instead of having two relations of the same 1000 members way, you can share the common boundaries between them (boundary in it's line sense, not it's area sense) So you will lower the number of members.

Mmmm.. by writing and thinking I might have understood now why you move the shape to another relation. When you say "Imagine the most usual case, when same boundaries is shared between for example juridical district and administrative state" Did you meant boundaries as the full ring ? Does it means you are used to administrative entities that are exactly the same shape, same members, same area but with different properties ? (This case doesn't exist in France, that's maybe why I had problem to imagine)

Couldn't the solution bet to had multiple properties then ? such as :

• boundary=administrative
• admin_level=6;8

Or, add one of the relation to the other having different properties ? That would keep simple cases simple, and the duplicate cases you mentioned still possible sletuffe 14:24, 31 August 2009 (UTC)

Here I was thinking more about case when shapes of regions are reused across different region_categories. Therefore you sould have shape of region given by multipolygon X and than two relations like:

first relation

• region_category = juridical
• region_type = prelature
• name = prelature of Baghvachtian
• X as boundary

second relation

• region_category = administrative
• region_type = district
• name = Baghvachtianic valley
• X as boundary

if we are going to add more then just one hierarchy (until now the only widely used is administrative), than this will be very common case, which is not expressable in current usage at all. Maybe you say something like

• boundary_1=administrative
• boundary_2=juridical
• admin_level_1=8
• admin_level_2=4
• name_1=Baghvachtianic valley
• name_2=prelature of Baghvachtian

but it is very ugly, so the solution would be to copy the whole list of ways defining boundary over and over. Note, that if we are going to work on different hieararchies (in my terminology noe region_categories), we will have to adress this anyway.

In the end, I would say that I'm in favor of it (as a first step) to provide this new schema for non existing solutions (seas, mountain range, postal zone, time zone,...) Globalisation could be covered later (if at all needed) sletuffe 20:31, 29 August 2009 (UTC)

Thank you very much for your ideas. My proposal is build on many existing practices and is really meant as little bit of cleaning up the existing state and provide expansible way for future development. I am aware of difficulty in pushing such complex changes, so I agree with you that it might be nice to use it for non-existing cases first. Maybe it can also be used parallely with existing cases to proof the concept and maybe some day (when it is supported by renders etc) transfer the "administrative case" to it. Would you please tell me, as more experienced user, how should I proceed to start looking for the agreement with the community on this? I can not find any definite tutorial on this. Thanks a lot. --Jakubt 22:51, 30 August 2009 (UTC)

the best way is to send a mail to the talk list where most of the gurus are ;-) [1]

I have been browsing the database little bit and I now have feeling that even the "administrative" case is not covered well yet. There seems to be some structure of relations going from planet, through continents (which is geographical step, so it mixes two things tohether), than skipping obviously administrative things like European unin, to country level and even on this some states are marked as country some as nation without any very clear guidelines existing. Possibly on more local level the system is more consistent in separate countries, but it is almost guaranteed that the practice will be different i different states. --Jakubt 23:55, 30 August 2009 (UTC)

could you give the id of the europeen union so I understand how it was built ? sletuffe 14:24, 31 August 2009 (UTC)

subregion role members

Maybe I don't have understood, but I think we don't need those "subregion" members. As long as what you define a "subregion" is an area (smaller or equal) in surface and totally inside the region, the subregion members have automatically a "geo-link" to region by beeing inside the region (and shareing the same region_category). So no need to explicitly add them as members. (any well working GIS software such as postgis or qgis is able to handle that correctly, no needs for another burden on the mappers shoulders) sletuffe 23:11, 11 September 2009 (UTC)

Well this is true, but is is kind of general problem all over the openstretmap project. There are many things which can be automatically derived from existimg data using clever enough software. On the other hand calculating over and over again the same thing can be time consuming and if the calculations is difficult enough even impossible for some ligher softwares. It is quite hard to say what is the best compromise between practicality and "purness" of data (i.e. strictly non including anytnihg that can be derived). If it was me to decide I would in this case keep suregion roles for their cenveniance and code an software which could maintain them aautomatically or semi-automatically. However I do not know all technical details about database etc., so I kght be overseeing some disadvantages of this opinion (I of course see some disadvantages, but it is always the case when making compromises) --Jakubt 20:40, 14 October 2009 (UTC)

Massif

What is the best way to construct the shape with relations ?

I'm copying some of Alessioz's comment here to give my point of view :

We have to think a good way to use Relations and eventually Relations of Relations for sub-groups of mountain ranges. Or is just enough the tag is_in=*? Alessioz 15:24, 5 September 2009 (UTC)

is_in=* is imo the bad way to go, GIS software have good ways to find what point is inside what area which is inside any number of areas, putting is_in every where will lead to oversight, additionnal work to mappers, data inconsistency.

But you are asking the good question : "how do we construct the shape of those areas using relations ?" sletuffe 23:37, 11 September 2009 (UTC)

Should we use a relation "Dolomites" to group all the mountain ranges of Dolomites (Sella, Brenta, Sesto, Latemar..)?

I think that yes, but not thinking as categories see : Relations/Relations are not Categories sletuffe 23:37, 11 September 2009 (UTC)

Firstly the groups of Dolomites are not close each other but sometimes separated.. for example Brenta Group is 50km separated from others but it is considered anyway part of Dolomites.

That is strange ;-) but that could be handled with relation of type advanced multipolygons with something like outer role member sletuffe 23:37, 11 September 2009 (UTC)

Then we could think to group the relation "Dolomites" into a Super-Relation "Alps" together with other groups like the "Mount-Blanc Massif" and others.

That's where I think it's not the best way to go. This looks like a category system, and constructing "the alps" might become tricky. All this looks like to drop to this problem : Do we construct relations used to map areas composed of other areas or from the boundary ways which forms the outline ? I think 2 is better, but have no solid proof sletuffe 23:37, 11 September 2009 (UTC)

The problem with this kind of groups is that we will get a Super-Relation of not necesarely contiguos areas and this is not good because Alps are all together without holes also where there are not real mountain ranges.

That's one problem ;-) sletuffe 23:37, 11 September 2009 (UTC) (Well, to be honest, the other solution has problems too) sletuffe 23:37, 11 September 2009 (UTC)

I think that forming higher level areas by composing them from smaller areas is not practical - it can gives whole hierarchy of relations and makes mapping difficult. Also it makes it quite difficult to say what are the boudaries of this higher level area - you should dismiss these parts of boundaries of sub-areas which have sub-areas from both sides - these parts are irrelevant at the higher level. And there are more arguments like that Alps are not only coposition of its individual mountais etc. If there are uses where it is beneficial to have direct links from higher level areas to its components, than I suggest using subregion role from Region prposal. --Jakubt 03:44, 30 December 2009 (UTC)

Massif - possible values of region_type

Hi, I see that your discussion about Massives is already well developed so I am interested in your opinion. I see that you deal with exactly the same problems as other hierarchies od regions, and I think that Relations/Proposed/Region covers that problem already. My question is:

What would be the best names for hierarchy of massives?

In the Relations/Proposed/Region there are these proposed values

 mountain range / massive / mountain

Could you think of some others? What are all possible options in your opinion. We do not need to decide anything final, the hierarchy can be adjusted later or can evn be different for different parts of earth (which is BTW one of the important features of the proposal Relations/Proposed/Region#It_allows_different_national_schemes_work_nicely_together). But still I am interested to know what would be the best possible values to start with, currently proposed values are ment as a starting point for the discussion.

--Jakubt 21:03, 14 October 2009 (UTC)

Massif - proposed category_type

Now there is a category_type = natural=mountain_range. Is this the good name? --Jakubt 21:03, 14 October 2009 (UTC)

Suggestion: type=region,region=topological,topological=massif|mountain_range.
I'd prefer to have massif, it's shorter; though some groups of mountains are called ranges ("Totes Gebirge"), others Massif ("Dachsteinmassiv"). But we are into mapping, not naming, right? --MerDi 18:00, 10 December 2011 (UTC)

Valley

Inspired by Proposed_features/Valley i have added category_type=valley to the proposal. We can use subregion=* for nested valleys.

There is no such thing as category_type=valley. It was halfway added as region_category=valley.

Suggestion: type=region,region=topological,topological=valley.
Might be extended as: type=region,region=topological,topological=valley,valley=gorge|runlet|ravine|swale. (and there are probably more, as I am not a native speaker.)

Or are these: type=region,region=topological,topological=valley|gorge|runlet|ravine|swale|rigde|anticline?
Or is it even: type=region,region=valley|gorge|runlet|ravine|swale|rigde|anticline|summit? --MerDi 18:00, 10 December 2011 (UTC)

Grouping without boundary

There seem to be a number of cases where it is desirable to group several objects without necessarily bounding them - perhaps relation=region isn't right for these, but in that case, it's worth consciously excluding them.

The cases I'm thinking of include groups of islands (e.g. in my area the Crowlin Islands, of which there are three, each with its own name, but labelled collectively on most smaller-scale maps) and also groups of lochans or other features that are not named individually. In these cases, the members of the relation would normally be simple polygons (or multipolygons).--tms13 23:29, 20 November 2009 (UTC)

Could you give more specific examples - I think that in your case of three islands the relation=region is perfect - you make one larger region which includes all three islands with name which is used for the triple and than you make smaller "subregions" for individual islands.--Jakubt 00:55, 19 December 2009 (UTC)

Probably a better example is that of several lakes with a collective name - though I suppose it's still possible to add a boundary to enclose them.--tms13 15:30, 20 December 2009 (UTC)

Au contraire - I think that Region is perfect for such cases. It allows to mark group of lakes by multipolygon and use this in the Relation to give name to the group of lakes.--Jakubt 03:30, 30 December 2009 (UTC)

Proposed Relation Name

I am not a native speaker, so handle with care.
territory: got a negative touch. Otherwise good but rather large. A territory is not a valley.
set: just to general
area: broad but stil applies to geographics. Would apply to smaller bbox's better: valley, ridge, ...
group: just to general
region: sounds pretty large to me, when it comes to valleys, e.g. But it's definitely geo-related and therefore a good choice.--MerDi 18:30, 10 December 2011 (UTC)

Relation Tags

I think the Relation Tags Table is a bit confusiong as of now; things that first do not appear in the "region_category" line, column "Value" later pop up in the "region_type" line, column "Value", sub-table column "region_category value" column.

I think the right way to go is
type=region,region=topological,topological=valley|ridge|gorge|summit|massif|range|... --MerDi 19:00, 10 December 2011 (UTC)

Sure go ahead and make it less confusing. Thanks for helping. --Jakubt 20:17, 20 January 2012 (UTC)