-
Notifications
You must be signed in to change notification settings - Fork 820
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
render ref numbers for allotments=plot #432
Comments
allotments key is currently not in the database - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style |
Is it something generally useful? I would be against rendering ref numbers of forests, allotments, highway lamps, etc etc. Roads are rare case where ref is widely used for an identification. |
This is useful if a friend wants to invite you to a barbecue on his plot. Also some people live permanently on plots, so this is their address of residence. |
with plots this would be equivalent to addr:housenumber only with a different operator of the numbers. |
According to the wiki, ref is used to identify the plot. E.g., plot 5 or plot C or plot D1. However, when I look at the example referred to in the proposal (mapped by the person who wrote the proposal) it doesn't have a ref but has a name: "1in12 Club's Peasant Collective Plot". I would say that, in general, it would be nice for the renderer to use name if it exists otherwise use ref if that exists. In much the same way that a house name is shown, if it has one, otherwise the number is shown. In addition to reasons mentioned above, this would be handy when people apply for an allotment so they can be told, for example, that plots 3 and 16 are available so they can go and see what's there unaccompanied. The wiki probably ought to advise against using names of people on plots because of data protection issues, but that's a different matter. |
Could be quite easy to do, since it should be just another element similar to |
I've asked about this on the tagging list first, because there are two
competing ways to show this: lot=<number> and ref=<number>.
The second is used over 6000 times and is mentioned on the current
allotments=plot wiki page (though it wasn't part of the proposal), but
the first is used over 1000 times and is mentioned on the
landuse=allotments page.
…On 12/1/18, kocio-pl ***@***.***> wrote:
Could be quite easy to do, since it should be just another element similar
to `addr:housenumber`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#432 (comment)
|
It looks like there is some support for using ref=* for these cases on the tagging list. While the numbers are fairly high, it looks like the usage is patchy. In many of the European provinces that I've downloaded there were no allotments=plot or at least none with ref=*, but I did find this one in Wales, and it looks like there are a number in Germany. It looks like we would need to add an outline for allotment=plot so that the numbers make sense? Cardigan, Wales https://www.openstreetmap.org/#map=18/52.08803/-4.64677 With numbers only (and current colors, no borders) - for comparison z18 - Ref numbers, plot and landuse outlines (and new color Currently we only show address numbers and unit numbers on buildings. I believe this would be the first time that numbers were rendered for a plot of land. |
Yes please. It not only makes the numbers make sense, it makes the map far more useful. Somebody asking by email about available plots can be given a link and the information that (say) plots 4 and 10 are currently available. That would allow them to visit the allotment and look at the plots without needing somebody there to point out which plot is which. I mapped that allotment based upon an image sent to me by the allotment committee of a drawing showing plot numbering. The reason that not all plots are numbered is because the image was unclear in places. I did ask for clarification but received no response. But that was after I told them that currently the plot outlines and numbers weren't rendered. If your change goes in I may be able to get more info out of them (another reason I support it). I know this is almost cadastral mapping, and we're not supposed to do that, but there is nothing to prevent me drawing physical boundaries (hedges/fences/walls) between properties that are almost cadastral, so I don't see this as being much different (I mapped those outlines because they showed up in aerial imagery). In any case, A foolish consistency is the hobgoblin for little minds. The only other thing I'd mention is that I later learned (but have yet done nothing about) that one of the plots has a name. It is now the "Collective Orchard" or "Members Orchard" or "Common Orchard" or some such. I have a record of the actual name somewhere but it would take me a while to dig it out. So is there any possibility of rendering a name, if present? If so, the wiki page would have to caution that this should not be used for the name of a person who is assigned the plot because of possible problems with data protection legislation. All that aside, I'm very happy with your proposal with the borders. |
It looks like Berlin has many allotments with plots and ref. (Allotments 1 and 8 render because I changed the file, by adding "area=yes"; the surrounding plots do not render. This also happens in areas without buildings) I can add a line to the lua transformations list, but I suspect this means we need to wait for the next database import to get many of these to render? Is it worth doing a PR for this now or do we need to wait? |
You should treat the area=yes on the Cardigan allotments as an aberration by a highly aberrant individual (me). Back when I added them the wiki page said to map them as areas. So I added them using iD's area tool and gave them refs. Not only did they not render, the ref wasn't used as a label by iD, so it was very hard to ensure I hadn't misnumbered anything. So I followed the link in the proposal to an example and found that plot didn't have a ref but did have a name. So I tried duplicating the ref in the name. iD then used the name as a label, but placed it on the way rather than in the centre of the plot. Which was still confusing because most of the plots have at least one common way and that's where the label often appeared. On a hunch I added an explicit area=yes which cured the label placement. So I committed a bigger sin than tagging for the renderer, I tagged for the editor. iD has since fixed this issue with the name and will place it centrally rather than on the way even without area=yes, but still doesn't use the ref as a label if one is present. In my opinion, the plots should have an implicit area property (like many other features) and not need an explicit area=yes. The Germans did the right thing whilst I cheated to make my life a little easier. I just subdivided three of the plots and removed the area=yes on them to see what happens. :) If whatever you do means plots won't render until the next db import, I can live with that. It's been 10 months since I first commented here, and the issue has actually been open for nearly 4 years. Another few days doesn't matter if it means we can do it right. |
Now that #3625 is merged, we could add outlines for plots in allotments.
Can I do a PR for plots even though the tag is not yet imported into the
database?
What is our policy about features that require database reload?
…On Tue, Jan 8, 2019 at 12:19 AM eehpcm ***@***.***> wrote:
@jeisenbe <https://github.com/jeisenbe>
Unfortunately, the plot outlines and numbers do not render here, because
these plots are tagged not tagged with "area=yes" like the others in Wales
(above).
You should treat the area=yes on the Cardigan allotments as an aberration
by a highly aberrant individual (me).
Back when I added them the wiki page said to map them as areas. So I added
them using iD's area tool and gave them refs. Not only did they not render,
the ref wasn't used as a label by iD, so it was very hard to ensure I
hadn't misnumbered anything. So I followed the link in the proposal to an
example and found that plot didn't have a ref but did have a name. So I
tried duplicating the ref in the name. iD then used the name as a label,
but placed it on the way rather than in the centre of the plot. Which was
still confusing because most of the plots have at least one common way and
that's where the label often appeared. On a hunch I added an explicit
area=yes which cured the label placement. So I committed a bigger sin than
tagging for the renderer, I tagged for the editor. iD has since fixed this
issue with the name and will place it centrally rather than on the way even
without area=yes, but still doesn't use the ref as a label if one is
present.
In my opinion, the plots should have an implicit area property (like many
other features) and not need an explicit area=yes. The Germans did the
right thing whilst I cheated to make my life a little easier. I just
subdivided three of the plots and removed the area=yes on them to see what
happens. :)
If whatever you do means plots won't render until the next db import, I
can live with that. It's been 10 months since I first commented here, and
the issue has actually been open for nearly 4 years. Another few days
doesn't matter if it means we can do it right.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#432 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshGg8QY5ZGbdOwPi0wRyZ_o_NbGTYks5vA2VxgaJpZM4BsD7z>
.
|
It hasn't been done yet, we just use hstore for such features. To be more precise, they are imported, they are all just stored as "key=value" in the hstore column (instead of "value" in the "key" column). Look at the healthcare code for example: #3498. |
~58% out of 11 360 plots have ref number tagged: https://taginfo.openstreetmap.org/tags/?key=allotments&value=plot#combinations |
I'm happy enough with the ref numbers, but do we need the outlines for the plots? |
I'd find it useful. So would others.
What is unimportant to one person is important to another. There are many POIs (such as women's clothing shops) that are of supreme disinterest to me, but I map them anyway because they are important to others. And even I may find such POIs useful for navigation. Picture also the scenario where somebody applies for a plot by e-mail They receive a link to the map with the information that plots 3, 7 and 12 are available. When I was obtaining information about my local plots by e-mail, I received a photo of a hand-drawn map with the plot outlines and numbers (the plot borders were distinguishable from aerial imagery given the hints in the photo). But some of it was too blurred to make out some of the numbers and the sequencing wasn't obvious. So I mapped the plots and numbered the ones that I could make out. When I asked for clarification of the remaining plot numbers I had to admit that currently the outlines weren't rendered. The previously enthusiastic person never responded, presumably thinking "What's the point when neither the outlines nor the numbers render?" And I'm left thinking "What's the point of going to the effort of mapping the invisible?" Given that currently iD doesn't display the refs as labels (although it does display the names) it makes it hard to check that I've numbered things right. Although rendering the refs would help, having the borders too would make some errors less likely. On top of all this, as an aside to responding to your question, I repeat my request that you consider rendering names if present (in the same way that house names are displayed as well as house numbers if both are present and there is enough room). Some plots have names as well as (sometimes instead of) refs: this from the example in the original proposal and |
do we need the outlines for the plots?
I tested rendering just the ref numbers above, but they were hard to
interpret without the outline.
For residential areas, we do not render plots
We render house numbers on the buildings themselves. This is a much better
solution for residential areas.
Allotments generally do not have houses or house numbers, so there is no
where to show the number except on the plot itself.
Re: residential plot outlines: I’ve always appreciated seeing these on
G____e maps at very high zoom level, but these may be harder to verify than
allotment outlines, where the shape of the garden beds can show the line if
there is no fence or wall. Is there an approved tag for these, or are
imports of lot lines discouraged?
… |
See the warnings in place=plot: OSM does not aim to be a land registry. You can add plot data if you want but only where the plot boundaries are actually visible on the ground. Do not import plot or land ownership data from third party sources. |
See polarbearing's warning. OSM is not intended to be a cadastral map. I sometimes plot walls/fences/hedges where these are both visible (whether on aerial imagery or from a survey) and useful in some way for comprehending the situation one may confront on the ground. For example, near public footpaths/bridleways, or on farmland used for public shows, or camping. |
That's pretty much how it operates. The owner might be an individual (unlikely) or an association, or a local council. The history of my local allotments is complicated. It has been in the hands of the county council and then the town council, it's currently in the hands of the allotment association but it reverts to the town council if that association disbands. As to which information is public, and how public, that probably varies depending upon the country and the owner of the allotment. But it doesn't really matter. Whoever owns the allotment is responsible for ensuring whatever data is made available complies with local data protection/privacy legislation. The allotment owner may have a publicly-accessible database linking plot holder's name to plot number. Or a sheet of paper in the window of a shed (as for my local allotments). It doesn't matter as long as we only show the plot number. If there is information relating plot number to holder's name made available by the allotment owner that is not our concern, any more than it is our concern if the list of those on the electoral register is publicly available (meaning that if our map shows a house number you can determine who lives there): house numbers are observable by anybody from the road. So not only is there no general cadastral database for allotment plots (not in the UK), even if there were it wouldn't be a problem because that information linking plot number to holder is made available by somebody else and would be available whether or not we map the plot numbers. If there's no cadastral information it's not a problem at all. If there is cadastral information then it's not our problem. Only if we map cadastral information would it (possibly, depending on the legislation in the particular country) be our problem. As for gmaps, I just checked for my local allotments. Not only does it not show the individual plots, it doesn't even show the allotment. Sometimes some POIs are hidden unless you actually query for them, which I just did. Still nothing. Gmaps doesn't (in general) show plot boundaries of anything in the UK. And it renders buildings as rectangles whether they're rectangular or not, and only of approximately the right size. |
I think the danger of showing living people's names is the same as in the name of the building - there might be places like that ("Old McDonald's farm", "My plot" etc.), which should be fixed, the bugs like this do not invalidate rendering numbers. |
For what it's worth, I would vehemently discourage the rendering of plot boundaries. This will encourage the mapping of plot boundaries, and this "mapping" will largely be imports of high detail and questionable use. We don't normally map plot boundaries in OSM. They are rarely verifiable on the ground. If there's a fence, map the fence. If there's a wall, map the wall. But you can't see where the plot is. So don't map it's outline, and don't encourage people to invent and map some outline it by rendering it. |
Actually, allotment plot boundaries often are visible on aerial imagery and on the ground. At least the ones near me are. What aren't visible are the numbers assigned to those plots. But they too are verifiable by asking the organization responsible for the allotments. |
There's been some pretty bad quality imports of residential plot data in America. I ts something that happens with everything though. I dont see why this should be the exception. Its not it cant just be cleaned up in this case like it is everywhere else Im also still mixed on how much rendering something inharently leads to an "x increase" or whatever in imported data of that feature. I think in the case of imports it has more to do with someone providing the data in the first place, because the opertunity cost of adding millions of features to the map at that point is so low. Even if it doesn't render. Going off that also assumes there's a bunch of plot information sources to import in the first place. Which probably isn't true. I doubt the venders of most allotments know how to turn there maps into shape files and id think its something to detailed for a state goverment to provide on a mass scale. Which is probably why Google doesn't provide it, Because its not avalible for import at any real scale, if at all, to make it worth doing. |
No, they are absolutely invisible. What is visible are physical objects that people erect along where they think their boundary is, e.g. hedges and fences. These are mappable and already rendered. |
We show field boundaries in farmland even when there is no fence, due to
signs such as different crops.
Allotments are similar to farmland in this way
…On Wed, Jan 16, 2019 at 5:23 PM polarbearing ***@***.***> wrote:
Actually, allotment plot boundaries often are visible on aerial imagery
and on the ground
No, they are absolutely invisible. What is visible are physical objects
that people erect along where they think their boundary is, e.g. hedges and
fences. These are mappable and already rendered.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#432 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshLm63X--narj6LgQbpusN3n4t_NBks5vDuF7gaJpZM4BsD7z>
.
|
No. It would be comparable if you mapped the flower bed vs. the veggie bed, that would be your different crops that are ground-verifyable. The different farmlands are different landuse, not legal plot boundaries. Plot boundaries are not ground-verifyable. The fence might be in a different place than the property boundary. A hedge would be planted so that its width does not cover the neighbours ground. Most famous example is the Berlin Wall, few segments remaining, which left a few meters of East German territory on the western side, thus everybody touching the wall from the west would stand on eastern ground. |
If I understand you correctly, using it for rendering refs would be OK, but explicitly showing it would be bad? |
This is not always the case. Take a look at these allotments in your favourite editor. Turn off the OSM data layer. You see those things that look like fences or hedges? They're not. I've been there and they're the boundaries between plots where the two relevant people are reluctant to go right to the edge of their plots in case they end up hoeing or digging a small fraction of their neighbour's plot. These borders are even more visible in a survey. I know that for a fact because I went there and had a look around. |
I already responded to a different part of your post, but something else about it kept niggling at me. I finally figured out what.
Yes you can. Maybe not on all allotments but on some of them. I know because I've mapped my local allotments using a combination of aerial imagery and survey. Most of the plots are clearly visible from one or the other.
And that's the bit that niggled me. You're implying that mappers invent stuff, and the more types of object we render the more they'll invent. If I can't figure out what something is, I don't map it. You make it sound like I'm in the minority. If you're right then we should all give up on OSM entirely, because by that thinking most mappers will just make stuff up because they can. |
They wouldn't know how and wouldn't see the point if they did know how. But they may produce a hand-drawn map for their own reference, as my local allotment association did, which they made available to me. Which confirmed most of the plot borders I could already see on aerial imagery and gave me the plot numbers. I consider that hand-drawn map to be an authoritative source and also verifiable (any other mapper could also request it, and a copy is on display at the allotment itself). But let me repeat, for the benefit of people who keep insisting that plot borders are invisible, that (at least for some allotments) those borders are clearly visible. Here's a question for the "invisible borders" people, and the "unverifiable" people. What if the operator of the allotments signed up with OSM and added the plots personally? What spurious objections would you then come up with to disallow them? I figure "local knowledge" is a legitimate source. I figure a hand-drawn map made by the allotment operator and made available to a mapper for the specific purpose of adding the plots to OSM is "local knowledge." |
If I turn off the data layer, I see the JOSM background. When I load Bing / DigitalGlobe / ESRI imagery, I see that the mapper has aligned the plot mapping sometimes to physical objects like flowerbed boundaries or hedges, and sometimes the boundaries go through the middle of an equally dark area. Vegetation is different on different images. So, what physical objects that delineates the boundary are you expecting me to see, and which aerial image are you looking at? |
That's what I mean. The refs can be treated similar to addr:housenumber, labelled from a node or the middle of a polygon. I'd not show the plot outline. |
It doesn’t look like the maintainers want to add new features such as these
until the next database reload, which could be some time from now. See #3644
…On Wed, Jan 16, 2019 at 10:00 PM polarbearing ***@***.***> wrote:
If I understand you correctly, using it for rendering refs would be OK,
but explicitly showing it would be bad?
That's what I mean. The refs can be treated similar to addr:housenumber,
labelled from a node or the middle of a polygon. I'd not show the plot
outline.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#432 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshDDnyQ3h4jyvmEAPc-PQlhS9Am7gks5vDyJpgaJpZM4BsD7z>
.
|
I'm glad you can see the hedges. Because there aren't any hedges. Those "flowerbed" boundaries are plot boundaries. They aren't even accumulations of weeds. They're the thin strip between plots where neither operator has dug/tilled the ground. And in many cases they're visible on aerial imagery. So much so that you thought they were hedges.
It's also different between aerial imagery and on the ground. A survey helped me identify some boundaries. As did the placement of sheds. And what also helped was a hand-drawn map the allotment operator sent me for the explicit purpose of adding the plots. Given the boundaries that were clearly visible in aerial imagery and/or on the ground, that map let me fill in the rest. That map counts as local knowledge, a permitted source. It is authoritative and definitive. And it's verifiable. A copy is displayed in the window of a shed on the allotment. It's not as verifiable as it could be. When I asked the operator for clarification about some of the plot numbers (too blurry to make out) I had to admit that currently they would not be rendered. The allotment operator lost interest in the matter. So I had the potential of making 20 people aware of the existence and utility of OSM, some of whom might then evangelize or even become mappers. Instead I have an allotment operator who probably bad-mouths OSM if asked about it. It must be me that's in the wrong. I had the bizarre idea that mapping things that people want to see mapped would help popularize OSM. |
Sigh. I can't understand the reasoning behind that attitude. Somebody adds or edits an allotment plot or healthcare hospital and it renders. That person is happy and moves on to map something else. Maybe, just maybe, there's a slender chance that somebody notices a healthcare hospital has rendered but one he/she mapped some time ago hasn't. If so, there's a good chance that person tries editing the old object and magically it renders. There's a slender chance that (on top of wondering why their object isn't rendered but other instances of that object are) the person checks github issues first, and realizes an edit will fix it. There's a very slender chance that the person (after noticing a rendering disparity) raises the problem on github without checking if it's already a known issue. Is delaying fixing a problem to any extent whatsoever better than a partial fix that will, subsequently, become a full fix? It appears the maintainers think so. I don't see it.
It's been 4 years and counting for allotment plots. Weeks or months won't make much difference. Years would become frustrating. |
This example proves me it's worth rendering plot boundaries.
I believe lack of decision is the worst thing when someone is waiting. We have more issues accumulated from 1,5 year, so it would be best to do database reload anyway. Let's hear the response from OSMF OWG first, so we could synchronize things - openstreetmap/chef#211. |
#3786 will import |
If ever it does get rendered, please consider rendering the name of the plot (if it has one), or the ref (if it doesn't have a name). Here is a very crude attempt with uMap at getting allotment plots to render with plot labels appearing, and the allotment label disappearing, at higher zooms; and borders appearing at medium to high zooms. Zoom out to see things disappear. Yes, it's ugly. I'm sure you guys can do it better. |
It is now possible to submit a PR to render this feature. Since v5.0.0 all allotments=* features will be imported as polygons when mapped as closed ways. |
What is the current status? Can we already estimate when the allotment plots will be rendered? |
If this is added as a feature will depend on:
Currently there are 13k https://taginfo.geofabrik.de/europe/germany/tags/allotments=plot#combinations If you look at how they are distributed and how they have been added there is a valid concern about the verifiability and potential privacy and legal database rights related issues. On the other hand there is evidently an active interest among users of allotments to use OSM to map their environment and that naturally includes the plot level addressing scheme used when it exists. My main concern here is that there does not seem to be consensus among mappers so far how this mapping of plot references relates to address mapping in OSM in general. If a plot reference is verifiable on the ground (in other words: if it is signed or if it is generally local knowledge among people in the area) it would normally be considered an address and would be mappable as such. And in OSM we don't tie address mapping to the mapping of land plots. By introducing rendering of plot references without there being an established way to distinguish between such references which are an address and those which are not we would introduce quite a lot of confusion. |
It could be nice to see a rendering of the ref=* numbers for allotments=plot. They represents parcels individual number.
http://wiki.openstreetmap.org/wiki/Tag:allotments%3Dplot
The text was updated successfully, but these errors were encountered: