As some more information for you why the colon isn't just restricted or limited to languages:

width:carriageway
cycleway:side:width
width:lanes
parking:left=*/parking:right=*/parking:both:width

I really see a wide-use tendency here to use colons for a lot more descriptions than just languages

Hi thanks for answering!

Yeah I know the key maxwidth - but that's a different meaning. It's the maxwidth for vehicles to pass through.

That's not the case here, width:max describes the maximum width of the physical properties of the road.

width is the basic width of the road. or minimum width, if any, maxwidth (for vehicles) would reflect exactly that.

ehm, rephrase:
maxwidth = legal width according to the wiki for vehicles.

width = physical width of the actual object/polygon in this case roads.

the widths I enter are" from width" to "width:max" as physical description to the object.

I see no such description in the wiki, as the wiki only uses "width" as physical description and no other keys.

if you are aware of other keys - I'll happy to learn about them.

I think why you see 47k maxwidth - because I use them too according to the wiki, is because they describe the legal per traffic sign maxwidth for vehicles, most mappers will map that for sure, as I do too.

but again - this is about the physical properties of the road itself, and not the legal max width for vehicles.

And I think most mappers don't map that detailed to go into that depth for mapping physical reality on the ground as to say the road is "from" and "to" when it comes to width.

But physical reality on the ground is a core principal of OSM right ;)

as for the :... where after the colon should only be a language key - that's new to me.

There's so many examples on osm where colons are being used for a lot more than just languages. Everywhere throughout the wiki I see colons being used for other tag definitions than language.

It's new to me this is restricted only to languages.

A good example here, to stick with the widths, would be: maxwidth:physical

here too after the colon is not a language.

Sadly this again describes basically the maximum for the objects passing through - not the actual physical maxwidth of the object.

I think generally this is on OSM missing, but please point me out the proper keys if you know them, the proper maximum and minimum of the physical width of the object itself .. not from the perspective of the object passing through.

Thank you for contacting me about this.

you're right the width:max is ambiguous in its meaning, so is the maxwidth:physical since it isn't really the physical property of the object but basically the same as simply maxwidth

but the width:max I'm referring to is really different from both maxwidth and maxwidth:physical - hence I'm using it since it's not the same.

as you are obviously not aware on OpenStreetMap it's legit to "invent" a new tag as long as it's being maintained.

As such - the note tag I'm sure you know what that means. Since it's a specific Filipino note - which foreigners most likely won't understand - and related to official government data - it gets the :ceo.

5:10 is a typo, should be a decimal

the source values may be identical for now - but that's not a God given fact is it ;)

In future someone might change data and thus add another source or even overwrite the source... to preserve the fact the width has it's own source it's according to the mapping convention totally legit to have a source for the general data and a source specifically for the width.

Feel free to look it up on the wiki if you never read about it.

I quote from, width=*

The source of the width information can be specified by source:width=*.

Feel free to update the wiki if you don't like this and wish worldwide we delete the source:width tags. I'm just following the conventions/wiki recommendations :)

Hi there, thank you for your contributions.

Three small remarks
1) descriptive names are not permitted on OSM. They belong in the description.
2) Baguio is not an administrative part of Benguet
3) house number should be really the actual house number, and not include data like neighbourhood.

For full address like 13 Purok 7 Barangay, etc..
you can use the proper addr:full key

Generally don't add addr information to name or description - properly formatting the addr:... keys is the rule.

keep mapping and adding more addresses please.

And in a case like this - where you forgot the street name, if there's no direct known street name, the mapping convention requires then to add addr:place instead, in this case that would be the same as addr:neighbourhood then.

See the updated corrected data:

changeset/141757301
---

Published using OSMCha: https://osmcha.org/changesets/141733112

Interesting - but the user doesn't give a source?

Because I have here the official data of the city Engineering office for our ongoing project to update all the street names in Baguio - I find no Kalye Kuripot in our data.

I'll have the Barangays throughout the city to look over all data once I completed all official street data on OSM.

Thank you - sometimes our data is wrong and OSM data, based on local user knowledge, is right :)

Hi Timmy - why is there still a "no straight on" restriction?

I think there shouldn't be any restriction there

I wasn't even aware someone put a no u-turn there.

but why is there a "no straight on" restriction?

you can just follow the road there, there shouldn't be any restriction if you ask me.

OMG back then when I started mapping jeeps I added descriptive names still?

*hitting my own head*

reviewed and issues fixes, as explained in Whatsapp - within 15min you can update OsmAnd and the routing works

Hi thanks for adding the names, but please remove the noname=yes next time.

I'm wondering, doesn't JOSM warn you about this? I get a warning when I leave noname=yes while adding a name.

Anyway thanks

Hi Justin, thanks for helping to update Baguio.

Are you sure about the name Kalye Kuripot? Houses along that street still have the address Kalye Pogi, can you tell me your source how do you know it should be Kalye Kuripot?

Looking forward to hear from you, thank you

this whole area I have the drone imagery for - and of over 150 other areas in the city - once you see as source:" CEO Drone Imagery" don't move it anymore as that's the most accurate polygons referenced to the DENR reference points which are according to the CEO <5cm accurate
---

Published using OSMCha: https://osmcha.org/changesets/140626460

I restored the original Baguio City Assessor's Office administrative boundary data.

And decoupled some other objects from it - please verify I left your data as much as possible intact after restoring the original data from the assessor's office
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/140622349

The white spaces I add for myself for readability - it's not actually a necessity..

All I mind about - this is a tourist city with a lot of foreigners..

I wish everyone, Filipino and non-Filipino, when they're here in the city but also abroad as some of my friends work in Dubai - and click on a phone number in whatever app they're using for OSM - that they're actually ringing the right phone on the other end LOL

+63 is automatically omitted for anyone within the Philippines, but everyone outside, like my friends in Dubai - it only works if the +63 is there.

the 0 is automatically placed by network providers worldwide where applicable to replace the country code.

This is actually an international telecommunication convention outside of OpenStreetMap, how phone numbers must be formatted so they always work.

https://en.wikipedia.org/wiki/E.164

But basically the 0 in front of network numbers we skip them according to the E.164 as the network providers hand that if a phone number has a proper international formatting in place.

Some countries the 0 doesn't even work, I know Russia for instance they use an 8 if I remember correctly from the time living there (which was also why back then I studied the case on international proper formatting of phone numbers because with my European numbering scheme using the 0 it didn't work LOL)

As for OSm - the E.164 is also recommended.

phone=*#Usage

where I then use the DIN 5008 pattern
phone=+<country code> <area code> <local number>

but even without spaces - it still works..

feel free whatever is convenient to you - I just think the DIN 5008 and E.164 if we all follow the standards - then we're good right? And it works for all people worldwide wherever they are :)

Ehm yeah sorry for my long text - I do write a lot hehe

node/10767927101

please check the latest update on the wording..

true, what's quality or not is open for interpretation - i'll take that out

I understand all these arguments, Eugenes proposal may be about the places itself and not the address, but if the places are tagged as quarter, and then the address is tagged barangay, it wouldn't know that barangay equals quarter right?

So that's why I figured it's more consistent if on the map the addr points to quarter.. since the places themselves are also tagged quarter as per Eugenes proposal.

as for the usage, I think you'll find if you skip the usage of the time before Eugenes proposal - and focus only on added and newly created places since that proposal, the ratio isn't 1:3 but already over 1:1 in favor of the quarter usage.

I wonder then - if the solution might lay in adding both.

addr:barangay and addr:quarter

This may seem double then - but at least it's clear for everyone

As for renderers/routers .. OSMAnd and JOSM doesn't know what to do with Barangay.. maybe Nominatim can find any tag/key/value combination, but the apps I'm using certainly don't know what to do with "barangay"

Maybe there's some special rendering plugin one can install I'm not aware about.

but again, I could imagine just adding addr:barangay and addr:quarter both .. since you're also argumenting that adding the same webstring millions of times into the database is the right practice I'm going to assume here you wouldn't oppose the idea of adding addr:barangay and addr:quarter double, as surely that won't go into the millions LOL

I do recon, now I got the boundaries finally - I started the practice to add country/quarter/ because Baguio back then had no boundaries..

but now we do have - today will visit the DENR for more updated data in this regard - we could indeed just omit both country and quarter/boundary completely.. since we now have the administrative boundaries right?

Maybe that's even better to just omit it completely from the addr:?

except at places where there's boundary disputes.. there it may still be wise then to add both addr:barangay addr:quarter to maintain physical reality on the ground vs official boundary how it should be, but isn't on the ground?

thanks for the discussion btw..

Hi thanks for the fast reply! yeah will re-align it a bit, thanks for the update..

cheers and keep on mapping

I'll put a fixme on it - any time I'm back at SM I'll walk around to confirm if it's really a name or just a description..

interesting - I always everywhere just added the short version because someone of the main OSM server maintenance guys once told it me:"it makes sense to minimize data to the absolute bare minimum to reduce load on the servers"

given that with the argument Erwin mentioned to me a few times:"we don't map for the renderers, they should adopt to work with the conventions we agreed upon"

he once told me - if there's something the community agreed upon and some app doesn't work with it - that's reason then to report it so they make it work - but it's not your task as mapper to convince the mapping community that the whole community must adept to a few apps or renderers who refuse to adopt the agreements within the community.

So all these arguments made me to just always paste the short version for the FB links..

Hmm, something I need to think about