pitscheplatsch's Comments
| Changeset | When | Comment |
|---|---|---|
| 185134297 | Hi, welcome to OSM. Could you please clarify how the added names are verifiable on the ground? Is it shown on a sign or commonly used locally as the actual name of these features? |
|
| 185130055 | Hi, thanks for your contribution! I noticed that the name=* tag for this isolated dwelling is set to '19', which seems more like a house number. Could you please clarify how the name '19' is verifiable, such as whether it appears on a sign or is commonly used locally as the feature's name? |
|
| 184994515 | Thanks @eerib |
|
| 185126587 | Hello, and welcome to OSM. Could you please clarify whether “King Tide Marketing” is a real, physical, publicly verifiable office at 74 Lyon Street, or whether this is a private/home address for your business? OSM should map on-the-ground features, not be used mainly as a business directory or advertisement. If there is a publicly visible/signposted office at this location, the business POI may be appropriate. If this is only a home-based/online business or a private address without a verifiable public-facing office, please remove the name, office, opening_hours, phone, and website tags from the address node. Also, please be careful when adding your own business information: it should be neutral, factual, and independently verifiable. Thank you. |
|
| 185119233 | Hello, and welcome to OSM. Could you please explain this edit? This changes a previously mapped building=house at 26 Hollyhock Lane into landuse=commercial, adds the name “YourSoCal”, a website, official_name, and contact email. From the tags and location, this looks like a private residential building rather than a publicly verifiable commercial feature. OSM should map real, on-the-ground features, not use a private house/building outline to advertise or list an online guide/website. If YourSoCal has a verifiable office or shop at this location, please provide the on-the-ground source and use appropriate feature tags. Otherwise, please revert/remove the business/website/contact/name tags and restore the residential building tagging. Thanks. |
|
| 185125427 | Same again: Hello, and welcome to OSM. I noticed that this changeset adds/keeps full personal names as name=* on many private houses/residential areas, e.g. “... xonadoni”. Could you please clarify the source and whether these are publicly signposted/verifiable names of the features, not resident/owner names or cadastral/household data? In OSM, name=* should normally be the real, commonly used/publicly visible name of the mapped feature. Full names of private residents/owners should generally not be added to houses or parcels, especially when they are not visible on the ground. Also, Bing imagery alone cannot verify those personal names or property boundaries. Could you please review these objects and remove the personal names / private ownership information where it is not publicly verifiable? Thank you. |
|
| 185124811 | Hello, and welcome to OSM. I noticed that this changeset adds/keeps full personal names as name=* on many private houses/residential areas, e.g. “... xonadoni”. Could you please clarify the source and whether these are publicly signposted/verifiable names of the features, not resident/owner names or cadastral/household data? In OSM, name=* should normally be the real, commonly used/publicly visible name of the mapped feature. Full names of private residents/owners should generally not be added to houses or parcels, especially when they are not visible on the ground. Also, Bing imagery alone cannot verify those personal names or property boundaries. Could you please review these objects and remove the personal names / private ownership information where it is not publicly verifiable? Thank you. |
|
| 185095140 | Thanks for your reply. I checked all aerial imagery available in OSM for this area. The previously mapped parking lot still appears to exist there, so in my view it should not be replaced by landuse=commercial with company-related tags. If LAS Companies is located inside a building, it would be better to map the company separately as a POI/office at the appropriate location in or near the building, rather than changing the existing parking area. The parking area should therefore be restored. Could you please correct this and restore the parking lot? |
|
| 185095140 | Hi, thanks for contributing. Could you please clarify this edit? This way was previously mapped as a parking area (amenity=parking), but this changeset changed the same way to landuse=commercial with LAS Companies LLC name/contact/address tags. If LAS Companies is an office located within a building, it would usually be better to map it as a separate POI/node or indoor/building feature with an appropriate office=* tag, rather than replacing the existing parking-lot polygon. Also, could you confirm the address? The mapped tags show 1021 11th Ave S #55331, but the LAS Companies website appears to list 1821 11th Avenue South, #55331 as the mailing address and 1021 Brocks Gap Pkwy, Suite 125 as the KW Hoover office. Would you mind checking whether the parking area should be restored and the office added separately with the correct address? Thanks. |
|
| 185078945 | Hi, thanks for working on the Ladakh district reorganisation. I can see that the 27 Apr 2026 Ladakh Gazette notification supports the creation of the new districts Sham, Nubra, Changthang, Zanskar and Drass, and it also lists the territorial limits by revenue village. However, could you please add a more precise source to this changeset / affected objects, ideally the official Gazette notification, rather than only `source=knowledge; research`? Also, the changeset comment contains political/editorial wording (“Pure Gerrymandering!”). The underlying boundary update may be valid, but it would be better for OSM if the mapping record stays neutral and source-focused. One more concern: the changeset note says Changthang district is not yet mapped, so the Ladakh relation is still incomplete even though Changthang is included in the official notification. Could you clarify whether the updated Ladakh relation is intended to be temporary/incomplete, and whether a follow-up changeset will add Changthang as an admin_level=5 district relation? Thanks. |
|
| 171145190 | Partly reverted by changeset/185078945 ? |
|
| 185053511 | Hi, willkommen bei OSM. Handelt es sich bei dieser
Falls ja, ist wohl der jetzt hier gemappte Namen nicht ganz richtig. Weiterhin könnten von der Webseite vermutlich noch einige Informationen hier ergänzt werden? Viele Grüße, Pascal |
|
| 185042789 | Hi, thanks for your contribution! I noticed that the name=* tag appears to contain an address. In OSM, name=* should normally contain the real-world name of the feature, as shown on-site or commonly used locally. Could you please adjust or remove name=* ? |
|
| 184994515 | Same as changeset/185001953 |
|
| 185001953 | Hi, thanks for your contribution. I noticed that some name=* tags appear to describe the current status of the feature rather than its actual name. In OSM, name=* should normally contain the real-world name of the feature, as shown on-site or commonly used locally. For access restrictions or property information, please use appropriate non-name tags such as access=*, private=*, or description=* instead of putting that information in name=*. Could you please adjust or remove name=* ? |
|
| 184996933 | Hi, thanks for your contribution! I noticed that the name=* tag for this bus stop is 'Fresh picked pantry'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature name? |
|
| 184984071 | Partly reverted by changeset/184984859 |
|
| 184984071 | Hi, welcome to OSM.
|
|
| 184959971 | Hi, thanks for updating the spring. I noticed that the name=* tag contains what looks like coordinates rather than a name. Could you please clarify how the name '44.7295350, 38.1650980' is verifiable, such as being shown on a sign or commonly used locally as the feature's name? |
|
| 184959734 | Hi, thanks for updating the spring. The name=* tag currently contains only 'y'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature's name? |