[RFC] Feature Proposal – Developer

General talk
,
22

Exactly, and I would not use developer=* as subtag to a building because I understand this information to be more PR data than geodata.

The topic here are buildings, not boundaries or power plants.

Thanks for clarifying that. So it would probably also be good to tolerate an opionion different from yours here in the forum without starting to lecture about the nature of OSM.

Please dont use such strawman fallacies to make the opinion of someone else look stupid. I did not vote for removal of any tag at all, I just expressed my opionion that a certain tag does not add value to a building and that I would not make use of it.

2 Likes
23

You’re right! I contacted a user in the UK which seemed to have added many ref:developer (many as in more than 6,000). He agreed that they’re not references but just names of developers. He changed all his ref:developer to developer.

New numbers:

ref:developer: 417
developer: 8,243

3 Likes
24

I suspect that the developer of a landuse=construction or landuse=brownfield is already routinely being tagged as operator=* or just name=* based on readily observable signs and such. The proposal could point out that potential use for the key, along with a photo of a construction sign that emphasizes the developer’s name. To the extent that the developer remains observable after the dedication, it could continue to be tagged with the same key, but that emphasis on construction could mitigate the concern that people are going to go around adding information about a building’s history even if it isn’t even interesting enough to be posted on the building’s dedication plaque.

I have a feeling that mappers will be confused about the distinctions between this key and some of the other ones I’ve mentioned. There will be edge cases with certain legal arrangements in some countries. For example, in the U.S., some real estate investment trusts have a relationship to apartment complexes that’s more like operator=* and/or brand=*. Come to think of it, the most natural use case for developer=* among the buildings I’ve mapped would be the developers of low-income housing projects (aka social housing estates).

1 Like
25

This is a wonderful idea, actually; developer conveys info that a mix of brand, builder and other similar tags wouldn’t. Clearly it’s such a natural thing that it’s been slowly mapped for more than a decade now.

Besides, services built atop OSM could actually use the data here to advertise the use of themselves in place of commercial mapping providers, which is a boost to our ecosystem!

My concern should be clarity on the value of the tag.

The talk page on the wiki discusses special-purpose vehicles — companies built by and for just one or a few real estate projects — to shield the parent company from legal liability.

What about subsidiaries? One of the biggest companies on the Philippine Stock Exchange is Vista Land and Lifescapes Inc (VLL), which, if you search for Vista on the taginfo page for developer keys, reveals zero results.

Meanwhile, one of its many subsidiaries, Camella Inc., reveals 11 results specifically under its trade name developer=Camella Homes, which takes up the vast majority of all developer=* uses here in the Philippines!

The proposal page should clarify IMO:
should the value be names of holding companies (like Vista Land [and Lifescapes] with 0 uses; or Ayala Land with 2 uses),
or that of subsidiaries, which in my experience are the consumer-facing names (like Camella Homes with 11 uses and Avida Land with 1 use)?

Additionally, I’d also like some discussion on a similar tag which would be very helpful to the goal of classifying development projects: developer:wikidata=* with 301 uses.

If that would be added to this proposal, I’d love it better.

4 Likes
26

I’m sorry, is there something wrong with mentioning underlying principles on OSM and how they apply to that tag being discussed? The tone seems to indicate term “lecture” in derogatory sense, as if transfer of related information is somehow unwanted.

I do tolerate (and in fact, welcome) different opinions; and that is prerequisite for a healthy discussion; but I hope that does not mean I should be prohibited from mentioning different opinions to counterpoint existing opinions being presented?!

I’m sorry if you felt I was trying “to make someone (you?) look stupid” :cry:. That was certainly not my intention! So here is my public apology for that. :heart:

I also do not see why you think it is strawman fallacy (“refuting an argument different from the one actually under discussion, while not recognizing or acknowledging the distinction”)?
I was not trying to “refute” any argument, I was trying to explain my opinion why both advantages and disadvantages should we weighted when considering removal of tag (and specifically that if there are no clear advantages to removing data, that mapper feelings should play considerable role). The point not being “proving that I’m right” but providing other viewpoints to increase their diversity, so better community consensus could be reached.

Isn’t providing such comments kind of a whole point of the RFC?

I’m sorry you misunderstood that, and somehow construed my comments as a some kind of personal attack, just because my opinions differed from yours.

I did not vote for removal of any tag at all,

Nor did I claim you did (nor am I even aware of any voting going on). But there have been several opinions expressed in a thread (and yours seemed aligned with them[1]) that were of the opinion that such data as developer=* does not belong in OSM; and one of the common ways of dealing with things that “do not belong” is to remove them, so I was trying to preempt that.

I just expressed my opionion that a certain tag does not add value to a building and that I would not make use of it.

And that is totally fine and I fully support your right to express that opinion and that is exactly what RFC is about! Thanks for sharing that opinion!
I hope we can however agree that does not mean that I have to share your opinion, or that I’m somehow not entitled to share my own opinion.

I hope this clears the misunderstandings; if there is still confusion not related to developer=* tag itself, please reply in PM so I can clear those.

Thanks and have fun mapping (even if you decide not to use developer=* tag :smiley_cat:)!

  1. so I reused same post to comment on that instead of opening another one ↩︎

27

That’s a great comment.

Similary, in Morocco, the holding company Groupe Addoha has 3 subsidiaries:

  • Addoha for social housing
  • Coralia for mid-range housing
  • Prestigia for luxury housing

I didn’t hesitate to tag each development with its right developer, not with the holding company. And this is reflected with the example you gave in the Philippines:

I guess this comes down to how each project is marketed. If it’s marketed as a Vista Land and Lifescapes project, I would tag developer=Vista Land and Lifescapes, while I would tag it as developer=Camella Homes if it was a Camella Homes project.

developer=* should always use the most publicly visible or locally marketed name, like the subsidiary/brand.

I’ll update the proposal to address these concerns.

Also a great point! This would help structure and link the different projects/companies. Another similar tag could be developer:website=*. I’ll mention these complementary tags on the proposal.

1 Like
28

I dont have any kind of expertise here so please take that into account when ai make my comments but:

It would seem that linking a buildijg to a wikipedia article / wikidata entry would provide a space in that dataset for this information to be recorded so it would make sense for any atrributes to align with relevant Wikipedia templates/ attribute model

The alternative is that ooenstreetmap attempts to create a whole separate set of building data - the extent of which couldnbe huge.

To be verifiable the actual legal entity that lead the development would be preferable in my view - that would allow veriifcation against public records - e.g. resource consents etc. - perhaps a developer brand could also summarise the data. Many developer names arent unique and disambuiguation could be difficult in smaller cases.

29

Over 80% of existing usage of this tag is in the UK. In the UK it’s common to have big housing developments where dozens or hundreds of houses are built by a single developer and then sold off individually. The tag is easily verifiable during construction when the developer puts up signs like this:

Even after construction is complete, the developer will often have a visible presence (sales office, show home), at least until the last home is sold.

These developments are landmarks: you might hear people say things like “turn right after the Cala Homes”.

I think it makes sense to record this. I suspect that some of the people who have argued against the tag aren’t really familiar with the concept of a big, uniform housing development that very prominently displays the name of a developer on a sign. In some countries they are just not very common. In countries where self builds are the majority of new housing (e.g. Germany), there won’t be as much need for the tag.

I also wouldn’t go out of my way to search historical records to find out who the developer was of some housing estate that was completed 20 years ago. I agree that isn’t really a good fit for OSM.

4 Likes
30

I also think the proposal would have a better chance of passing if it explained this, maybe with some pictures from Morocco and the Philippines as well (which have been mentioned in this thread).

2 Likes
31

This is exactly what I’ve been using builder=* for, and also operator=* for the building=show_house office=construction_company while the development is still being filled out.

I still think it’s going to be difficult for mappers to know when to use builder=* versus developer=* for residential developments. As I understand it, the idea is to distinguish between the general contractor and any subcontractors. In the U.S., this distinction makes sense for large commercial real estate developments and public works projects. By contrast, in residential real estate, the homebuilder usually handles everything “in house” from start to finish – everything from purchasing the land to building the houses to putting in landscaping around them, other than maybe contracting out for electricians. So I guess both developer=* and builder=* would have the same value.

By the way, builder=* has been documented for about a year and was used significantly more often until June 20, when ref:developer=* was replaced by developer=* on a big batch of houses in South West England. Based on the current developer=* documentation, most of these occurrences should be moved to the surrounding landuse=residential, which will bring the total back down to what it was before this RfC, well below builder=*.

1 Like
32

Maybe that’s the case in the US. And if we follow the definitions of both tags, having the same value in both developer=* and builder=* wouldn’t be incorrect, because the same company, well, developed and built the project. However, in countries where different companies usually develop and build projects (which are more numerous than one), I think this distinction is still important.

You’re completely right about pictures, that’s exactly the type of verifiability I was looking for and that some people don’t understand. Another (bit blurry) example from Morocco (here, developer=Kettani Immobilier):

image
image384×512 83 KB

Or from France, developer=Vinci Immobilier):

image
image900×505 61.5 KB

Good point, that is why I mentioned the developer:wikidata, developer:wikipedia and developer:website tags in my proposal.

1 Like
33

I hope we don’t encourage developer:wikipedia=* too much. It does follow a longstanding pattern of *:wikipedia=* tags, but it’s wholly unnecessary when developer:wikidata=* exists.

2 Likes
34

I also agree developer:wikipedia sounds a bit useless and I am encouraging developer:wikidata more myself, at least in my area.

1 Like
35

and what about after last house was sold? What about residential areas built 5 or 15 or 50 or 150 years ago?

it becomes historic info, out of scope for OSM

I am entirely familiar with them, including practice of this signs being dismantled when not needed anymore

sometimes there is more permanent credit, sometimes there are archival records - but typically it is unverifiable by on the ground survey

again, I am familiar with them. And I understand that such signs are unlikely to be present for housing areas sold out 20 years ago.

This proposal page gives false dichotomy of “never verifiable” and “no problems with verifiability”. And fails to address raised concerns. And just assumes that people have not seen temporary ads for developers.

1 Like
36

How can you verify by on the ground survey that a building was indeed built in 1934? How can you verify that architect=Mateusz Konieczny? How can you verify that there are 2 underground levels or that there are 15 units in a private property if you can’t enter the property? How can you verify the opening hours of a place if they are not displayed? How can you verify the official name of a place? People should let go of the “how can I verify this on the ground” argument. Of course some people have more (local) knowledge of a place than you do.

What about developer logos that stay forever at the entrance of a housing development? Don’t these deserve to be mapped?

And guess what, developers can post these ads on the Internet and social media too, not only on physical signs! And on the Internet, these ads stay forever! What a great invention.

More seriously, as @Minh_Nguyen mentioned, if someone tags that a building/housing development was developed by Cala Homes, it means the info came from somewhere. Either a sign during construction, a sign after construction, the info came from their website, their social media… If you don’t know who the developer is, someone else might know it. And they decide to put that piece info on OSM. Simple as that.

If you don’t know the developer… don’t add it. But I don’t see a reason for prohibiting others from adding this information, which is useful to their eyes.

37

I am also against unverifiable historic tagging using start_date and architect.

asking employee

signage, current official documents in a pinch is also usable

Ads are definitely mappable.

And in such case I would be fine with tagging developer= - unfortunately proposal as is fails to mention that in some cases it is not possible to do properly

  1. many residential areas predate Internet

  2. no, they do not stay forever on Internet either, see Link rot - Wikipedia

what about cases where source is gone (say, sign was dismantled, ad is gone etc) and it is not possible to verify it anymore?

38

I guess “builder” implies they have actually built it, vs. developer who would have developed it and then engaged a builder to build it?

1 Like
39

What about these? It may still be possible to verify them, e.g. ask someone, look at an older photo, etc?

1 Like
40

it is usually verifiable, at least the period can often be narrowed down, even if you are ignorant and cannot distinguish a 1930ies building from a 1970ies one, e.g. by comparing historic images. Often there are also inscriptions and in the case of more significant buildings there may be plates on the ground, books, etc.

1 Like
41

In other words, it requires as much historical research as mapping 100% completely demolished buildings

in my opinion it would be better to keep it out of OSM

2 Likes