Add place=allotments

[AMDmi3]

This tag is widely used in Russia: http://wiki.openstreetmap.org/wiki/Tag:place%3Dallotments however it not being rendered makes people unhappy and lead to incorrect tagging, so I hope we can finally implement it.

There's also a ticket (14 months old!) for it in trac: https://trac.openstreetmap.org/ticket/4486

[al--]

Just curious: why not use place=hamlet? Is obviously is a form of settlement.

Alotments OTOH are a form of "common gardening", dachas don't have that much to do with this, I would say.

[dieterdreist]

2013/9/3 al-- [email protected]

Just curious: why not use place=hamlet? Is obviously is a form of
settlement.

Alotments OTOH are a form of "common gardening", dachas don't have that
much to do with this, I would say.

I wouldn't use hamlet for allotments, the latter are (as you also state) a
form of gardening (usually not intended to live there, usually it is also
forbidden), whilst a hamlet is a settlement (usually intended to live
there). For me allotments don't belong into place but into landuse, so -1
to render them (there are also only 1250 cases in the db right now, opposed
to 98300 landuse=allotments).

[AMDmi3]

Just curious: why not use place=hamlet? Is obviously is a form of settlement.

The main point is that these are not settlements officially (while technically they are very close to what we tag as hamlets): they are not mentioned in address registers (КЛАДР), don't have official postal addresses ( addressing mentioned on wiki is actually just a lot numbering, which may be used for navigation, but not for e.g. mail delivery), people can't register themselves there (http://en.wikipedia.org/wiki/Propiska_in_the_Soviet_Union), they are marked with different kind of landuse in cadaster ("Lands of agricultural purpose / Земли сельскохозяйственного назначения" vs. "Settlemend lands / Земли поселений (земли населенных пунктов))") and there may be many more unapparent differences. That said, we very much need to distinguish these kind of places from official settlements.

Alotments OTOH are a form of "common gardening", dachas don't have that much to do with this, I would say.

There's much confusion in terminology and even in what landuse to use. There are places with different amount of "allotmentsness": for example these are real allotments, while this is pure residential area. Mostly it's like this and gardening is highly involved so a definition from wikipedia "Allotment (gardening), a small area of land, let out at a nominal yearly rent by local government or independent allotment associations, for individuals to grow their own food" (from Wikipedia) is quite conforming.

[AMDmi3]

For me allotments don't belong into place but into landuse

It is absolutely incorrect to mix landuse and place and replace one with another - both are required as they tag different entities. landuse only mark (obviously) how the land is used, and (with accurate mapping) only belongs to lots themselves (not the access roads, fire water ponds and other infrastructure). place=allotments polygon, otoh, is used to mark the object as a whole, name it and is itself used to support addressing (or lot numbering) (e.g. addresses inside that polygon may be geocoded as ", ").

This is how our allotments are mapped - you can see there are blocks of lots, tagged with landuse, and the whole area with it's own border is (and must be) tagged as a place. All not really different to landuse=residential and place=city (and landuse=residential may be used in place=allotments as well). The only problem is that place tag is not supported by the current style, so hacks are used - in this case landuse=allotments node with a name to display a label. This won't be needed after this pull is merged.

[dieterdreist]

2013/9/3 Dmitry Marakasov [email protected]

It is absolutely incorrect to mix landuse and place and replace one with
another

+1

[Zkir]

Hi Guys, is it possible to accept this pull request?

place=allotments is popular tag in Russia, it is documented on wiki, difference between it and other types of settlements is obvious for Russian mappers, it is supported by converters into navigators (e.g. CityGuide), but people are realy unhappy that it is not rendered by mapnik.

http://taginfo.openstreetmap.org/tags/place=allotments
http://wiki.openstreetmap.org/wiki/Tag%3Aplace%3Dallotments

[pnorman]

Feature requests like this would fall under 3.0 on the plan in the readme which we're not at yet. It's up to andy of course, but I wouldn't expect to see this PR considered before then.

[gravitystorm]

Here is my thinking:

In OpenStreetMap we have a list of place values, from giant settlements down to single buildings. (city, town, village, hamlet, isolated_dwelling). This is a continuous range - any settlement can fit into this hierarchy, based on their size - and there are no gaps in the hierarchy. So every settlement can be categorised by using an existing place tag.

In some areas, there are other settlement classification schemes, usually run by governments. For example, in the USA there are medium-sized-settlements that are "incorporated" and so are referred to as a "City" by the government, and "City" is often in their name too. However, in OSM tagging terms they are place=town or place=village, and the extra legal details about their classification by government are captured by other tags if it is felt by mappers that some aspects of their status aren't adequately covered by place, admin_level etc tags. For example, the border_type=city tag has been used.

I'm therefore against the idea of place=allotments, and would recommend tagging them using the standard place= values, along with a second tag to distinguish the concepts of your "official" settlements from these particular settlements. I can see that the difference between them is important, but they still require a standard place tag.

[Zkir]

Hi Andy,

I feel sorry about such attitude. place=allotments tag is used and will be used, since supported by other applications. The only people who will suffer are mapnik users.

P.S.
Please also note that Russia is most probably the only country with own tagging scheme for places.
(i.e. http://wiki.openstreetmap.org/wiki/Place page is very generic, but must be something like http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative or http://wiki.openstreetmap.org/wiki/Highway:International_equivalence, with country specific rules and values)

[jremillard]

We render other tags with ~1200 instances. I just counted 260 unique user ids that have touched objects tagged with place=allotments. I think this decision is very disrespectful to them. If you are software developer, exactly how many mappers is your opinion worth on tagging style?

I am OK not accepting the PL because you want to fix bugs for the next 4 months, it renders ugly, it is too slow, it break something else, uses tabs when README says spaces, etc, but not because the tagging is dumb.

[gravitystorm]

@jremillard I'm the maintainer of this project, and in my eyes, there's a lot more to being the maintainer that just choosing what colours to use or rendering anything with more than X number of occurrences.

You've accused me of being "very disrespectful". Explaining my reasoning is not being disrespectful. I can disagree, politely, with any number of mappers without it being disrespectful.

It's disappointing that both reactions to my decision have ignored the given reasoning completely. I've thought about it long and hard and taken care to explain my thoughts thoroughly. If, however, the counter-reasoning boils down to "this tag is used, therefore you must render it, and we won't listen to anything else you have to say" then that's a reasoning that's going nowhere.

[jremillard]

No Andy, nobody wants you rendering everything that is used. I understand perfectly well, that not every PL is going to be merged in. My point is that your decisions to take or not take a pull request should be centered around the style sheet. So, if you had said any of the following, it would be in bounds.

• We are fixing bugs right now, please come back later.
• This is a regional tag, we don't want it in the global style sheet.
• This specific feature is just not important enough, say fire hydrants.
• This PL stinks, bad formatting
• This PL stinks, bad color,
• This PL stinks, performance issues
• This PL stinks, poor organization, etc,
• This PL stinks, not merging because it is old, rebase it.
• This PL stinks, it has tabs in it and I like spaces.
• This PL stinks, you changed the wrong files
• This PL stinks, it breaks something else

Or specific to this tag

• Send me a patch that renders it just like place=hamlet

But your response was a pure tagging discussion. It should be happening someplace else besides github. There are lots of ways for you to say so no to a PL that are in bounds. We have plenty of goofy, redundant, poorly thought out tags in use right now, the style sheet should by trying to not get to far ahead of the actual mappers.

[matkoniecz]

I think that style sheet should encourage tagging that makes sense. See https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md - especially "The Mapper Feedback Loop" section - it seems that maintainer of this repository has a similar opinion.

[Zkir]

It's disappointing that both reactions to my decision have ignored the given reasoning completely. I've thought about it long and hard and taken care to explain my thoughts thoroughly.

Andy, thank you very much for finding time in your busy schedule and explaining us the reason of your decision. The reasoning is quite clear.

However, the Russian community does not find it very convincing. Some explanations why the standard scheme is not suitable for Russia you can find here: http://wiki.openstreetmap.org/wiki/RU:Key:place/Clarification

So the local tagging scheme which is being used for 3 years differs a bit from what you describe. The used classification criteria include not only population, but also official status and type (rural or urban). There is also additional value for the place tag: place=allotments for the special type of settlements.

This question was broadly discussed in the forum; the tagging scheme has undergone formal proposal procedure, including RFC and Voting: http://wiki.openstreetmap.org/wiki/Proposed_features/Place_In_Russia

I can disagree, politely, with any number of mappers without it being disrespectful.

In his home project, one can do whatever he likes, and disagree with the rest of the humanity (politely or not, does not matter), but in the community project (I guess the map on the osm.org main page is some kind of a community project) the maintainer should have some obligations to the community.

[d1g]

In OpenStreetMap we have a list of place values, from giant settlements down to single buildings. (city, town, village, hamlet, isolated_dwelling). This is a continuous range - any settlement can fit into this hierarchy

@gravitystorm yes, but these classes were extended according to governmental data ("Схема на основе официальной классификации"

9(11) classes from here, cover every case from official docs, where 5 "worldwide" classes unable to describe all cases.

It is most important to support 5 classes that overlap first (you named them), but it is less important to support regional-based schemes. Nerveless, we should support them over time because they give much more meaningful and usable (practical) results.

[matkoniecz]

9(11) classes from here

Is there an English-language documentation describing why yet another new values for key place were invented? Especially - what was so important reason that such drastic solution was used instead of using additional tags, that would play together with well established place tags?

For example from reading http://wiki.openstreetmap.org/wiki/Key:place it seems that place=allotments is for place=farm/isolated_dwelling/hamlet/village without some legal permit. I am quite curious why place=* + some additional tag was considered to be an inferior solution.

And note - I am looking for link leading to such documentation (this bug tracker is not a good place to create one).

[d1g]

@matkoniecz quick reply regarding 3 classes, suburb,quarter,neighbourhood it was here forever, before PR:

Hierarchy for parts of settlements: suburb,quarter,neighbourhoo
http://wiki.openstreetmap.org/wiki/Proposed_features/place%3Dneighbourhood

Some styles use suburb,quarter,neighbourhoo data reasonably well at low level zooms (MapSurfer.NET)

[d1g]

@mackerski problem with place=* key is that it was defined as "named place"; and yes you couldn't blame anyone for tagging it place=* if object had name. It was never limited to 4 classes.

For example, place=island may belong to "natural" tags. BUT don't forget that there every single island within agglomeration with given name:

http://www.openstreetmap.org/way/26767311
http://www.openstreetmap.org/relation/1312631

I think one answer about place=allotments can be in their architecture and urban/rural planning.

As you can see; there no farms: http://taginfo.openstreetmap.ru/tags/place=farm but there http://taginfo.openstreetmap.ru/tags/place=allotments

Farms are typical for countries with farms, I don't think anybody could give definition what farm is. Can you define place=farm for every country?

Why do you want to place farms among (city, town, village, hamlet, isolated_dwelling)? How can you decide if farm is a village/hamlet/isolated_dwelling?

I understand intent to "keep it simple". But if you make it simpler than it is in the real life, this data will be less useful.

My opinion is that place=allotments can be seen as synonym to landuse=allotments.

AMDmi3 suggested to render them as farms is a good enough approximation for currently tagged objects IMO.

[dieterdreist]

sent from a phone

Il giorno 27 giu 2016, alle ore 14:28, d1g [email protected] ha scritto:

For example, place=island may belong to "natural" tags.

-1, the natural tag for an island is the coastline, if the island has a name we will use the place object for the name. A name on the coastline refers to the coastline.

[dieterdreist]

sent from a phone

Il giorno 27 giu 2016, alle ore 14:28, d1g [email protected] ha scritto:

My opinion is that place=allotments can be seen as synonym to landuse=allotments

yes, the place implies the landuse likely, but landuse=allotments don't imply individual places. The requirement of the place=allotments tag, according to the wiki, is to be a settlement outside another settlement.
I think it should be rendered similar or like a place=hamlet.

[matkoniecz]

My opinion is that place=allotments can be seen as synonym to landuse=allotments.

In that cases just use landuse=allotments.

[d1g]

In that cases just use landuse=allotments.

No. Because some of them are landuse=residential. As was said in message 4 and 5.

place=farm may used with landuse=residential; or with any other landuse and not limited to "farm"
place=farm doesn't imply landuse=farm (why do you think place=allotments would?)

[d1g]

landuse=allotments can be unnamed and sliced as many times as user(s) would like, but

place=allotments should represent only one named entity (Для присваивания названия объекту "дачное товарищество")

[mboeringa]

landuse=allotments can be unnamed and sliced as many times as user(s) would like, but

To be honest, it would be far better if a new tag was introduced to define subdvisions, instead of re-using the existing tag. Just like there is now a cemetery=sector tag (http://wiki.openstreetmap.org/wiki/Proposed_features/Cemetery_sector), for the landuse=cemetery tag (http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dcemetery).

[jojo4u]

Most of the rationale in https://wiki.openstreetmap.org/wiki/Tag:place%3Dallotments does not hold for me. Place is not about "official" status or cadastre. The seasonal/second home argument is reasonable for me.

I also have the problem that place=allotments has no population hierarchy and thus prominence on the map cannot me infered. There are only three place=allotments with population=* with values of 9, 200, 300

[dieterdreist]

sent from a phone

Il giorno 29 giu 2016, alle ore 10:11, jojo4u [email protected] ha scritto:

I also have the problem that place=allotments has no population hierarchy and thus prominence on the map cannot me infered. There are only three place=allotments with population=* with values of 9, 200, 300

btw, the population values we typically have on place objects are in many or maybe all cases population values of the enclosing admin area

cheers,
Martin

[d1g]

@jojo4u

Most of the rationale in ... does not hold for me.

Well yes, we have to say more. also Wikipedia is 35K big but not-so good about it. We have real farms (with farmers-owners, real equipment, regulated by law, with real buildings and not multilevel sheds that can't hold Russian winter).

Allotments are different from "farms" because often you cannot have real equipment (say, tractors) permanently; law says you can't live there permanently; area is quite limited (but you can own several plots or pay for a non-standard plot) and thus you can't make allotments as your business model. You either get small money or goods/food enough to feed family. You never overproduce 100x times more than you can possibly consume like farmers do, you never have to keep tonnes of goods somewhere.

Allotments in post-soviet states sometimes were used as leisure (think of BBQ site) and other owners raise nothing but grass or flowers or rare plants just for fun.

Some allotments (sometimes just individual plots) are now abandoned because overall hype is gone today ("The 1980s saw the peak of the dacha boom").

In this sense, allotments are different from "rice plantations" seen in Asian countries (I have to grow rice in dirt to feed my family) and from traditional farms ("I will overproduce to get money or to feed my entire village"). You never know how exactly each plot is used or is it used at all. Yes you may go serious with your plot, but that's untrue that everybody does this (there many drawbacks and inefficiencies).

You will never see a true farmer using his lands for BBQ or to grow something for fun or use his land only every 3rd year because he lost interest in this.