Hello,

I see you requested a review, and I noticed you are mapping private driveways with the tag private=drive. This is a very obscure and underused tag that has no compatibility with routers. In the future, I highly recommend using the tag access=private for such driveways.

But big thanks for taking the time to map out driveways. This is a huge help for delivery drivers that use OSM data!

Ah, sorry about the confusion. I was a bit misled by the meaning of the tag private=yes on these roadways. I've since fixed the access tags and added some additional lane tags and street-side parking areas.

Thanks for checking. I know this used to be signed as a private road, but if access isn't strictly prohibited, I'll change it to =permissive with ownership=private.

Gotcha. Sorry for the confusion. I'm not particularly familiar with this landmark. Rather, I've just been contributing to a global cleanup of the private=yes tag. But like to check in when I come across other things that look unusual.

Hello Amin,

I want to confirm whether the names of these cottage buildings refer to the buildings themselves or if these are the surnames of the occupants.

The latter scenario would raise some privacy concerns and is against OSM best practice, as this platform is not meant to contain personal non-professional data about people.

For more information on use of the private=* tag, see below.

private=*

Hi Ilovemap1999,

My apologies if I'd made some errors in my previous changeset, the assumption of access=private is that only authorized entrants and staff can access a road, while access=no implies that the road is completely inaccessible at the current time to everyone.

I notice some roads are tagged with access=no + private=yes. What is meant by this?

Note that private=yes is not compatible with routers and renderers and is considered a tagging error. This tag should either be removed, replaced with access=private (if the roadway is privately accessible to staff), or replaced with ownership=private (if the roadway is privately owned).

Hi CrysMelyn,

I notice you're using the tag private=yes to denote road and trials that are not publicly accessible.

In the future, to avoid routing issues, I highly recommend using the more globally standard tag access=private, which is compatible with most navigators and map visualization platforms. See more info on the private=* tag below.

private=*

Hi Shinterro,

I notice you used the tag private=yes to designate a playground that isn't publicly accessible. I strongly recommend avoiding this tag in favor access=private, which is universally accepted by data consumers and renderers alike.

For more information, see the wiki page on the private=* tag here:
private=*

Hi Socks,

I notice you used the tag private=yes to designate roadways as private.

I would strongly advise using access=private, which is the standard tag compatible with most routers and map display platforms.

Certainly. I checked TagInfo and saw there were very few cases of recycling:flags=yes, so we're not going up against a very established tagging schema to begin with.
Considering these retired flags are most likely being cut and burned rather than having their material recycled into new flags, it better fits the definition of disposal than recycling.

Hi, this seems to be a similar case to what you're describing. It was my first time encountering a feature like this. I will switch it over to your tagging scheme.

Hello,

Thank you for adding the commercial branch of your business to OSM. Once again, please avoid using the "Description" field for advertising purposes. This is not a place for subjective biographical information.

The following description has been removed:
"Robert DeFalco Realty’s Commercial Real Estate Division is proud of its achievements in the Commercial Marketplace. We have successfully negotiated Sales Contracts & Leases on all property sizes & types."

Hello,

In accordance with OpenStreetMap common practice, please avoid using the "description" field for advertising purposes. This field is meant to include objective information about objects in the OSM database.

For more information on how the description tag is to be used, see below.
description=*?uselang=en

Hello Alexander,

The building at 128 Mills Ave has already been mapped. Rather than adding a point at this location labeled "house", I added tags to the building polygon to designate it as a dethatched house.

Hi Flupie,

I went ahead and re-tagged all other parking areas you had added in Katendrecht. The larger parking areas have been added (this is why there is now one "P" symbol for every row of street-side parking spaces). They may be challenging to select in JOSM because of how they overlap completely with the parking stalls inside of them. I recommend using a lasso selection tool if you have trouble selecting an overlapped area like this.

If you are interested in mapping more street-side parking areas, here is a direct link to one of the larger parking areas I added for reference. way/1311878465

Hello Flupie,

Thanks for contributing very detailed information about individual street-side parking spaces. Though I recommend mapping these parking spaces using amenity=parking_space in the future. You can then add one large amenity=parking polygon around the entire set of parking spaces. This way, you only need to add the fee, zone, surface, and orientation tags to one element.

This is the standard way of mapping street-side parking on OSM. More info can be found here. parking=street_side

I have converted one section of parking spaces in this changeset, and I would be happy to help update any other parking rows you have previously created in this area. changeset/155900249

Best regards!

Hi Quincylvania,
I notice you tend to add the parking=yes tag for slipways and access points that have nearby car parking available. I would recommend not using this tag on elements which do not have the tag amenity=parking. It's customary in OSM to map parking separately from business, building, and other amenity elements.

parking=yes and parking=no are considered a common tagging errors according to the Wiki: osm.wiki/Key%3Aparking

Hi manof25,
I think you may be using the wrong tag to denote street parking. The parking=* tag is to be used on parking lots to denote the type of parking (e.g. surface, rooftop, underground, etc.). It should not be used on roadways.

For roadways, consider the parking:left, parking:right, and parking:both tags to denote the presence of parking on either side of the street. See the wiki below for reference on types of values that can be used for this tag.
osm.wiki/Street_parking#Parking_position

You may also use tags like parking:both:orientation to denote the configuration of parking spaces in a standardized manner that data consumers can use. parking:both:orientation=*

Both of the aforementioned tags are built into the iD framework, and you can more conveniently access them while editing a roadway via the tagging field drop-down menu by selecting "Parking" and "Parking Orientation" respectively.

The descriptive parking values you currently provide (e.g. "Mo-Fr school run-time single yellow lines") can be added as a note on the roadway using the note=* tag.

Hello, I saw that you had requested a review for this addition to OpenStreetMap. Thanks for taking the time to add your business! I noticed a few tagging issues which I have addressed in the changeset here:
changeset/154319605

- Removed "description" field. As a standard practice, OSM does not allow any subjective advertising or promotional material in a business's entry in this database.

- Removed logo image URL from "image" field. This field is meant for a photo unique to this business location. Brand logo images can be added to businesses on OSM by creating a wikidata page (for the Robert DeFalco Realty brand) and linking that page containing the brand logo to the business node on OSM using the "wikidata" tag.

- Revised "tiktok" and "youtube" tags to the standard "contact:tiktok" and "contact:youtube" tags.

- Revised "language" tag to use standard format with language:en=yes + language:es=yes and language:zh=yes for English, Spanish, and Chinese service languages respectively.

If you have any further questions or comments, please reply below.
- Revised "start_date" tag to use standard YYYY-MM-DD format.