aharvey's Comments
| Changeset | When | Comment |
|---|---|---|
| 164793552 | 9 months ago | It's been pointed out previously to you at changeset/162379793 that Landgate data can't be used to update data in OSM, their data is copyrighted they don't permit OSM to use their data, as such we can't risk using it. |
| 164925685 | 9 months ago | foot=* is meant to be used for legal accessibility, and legally you can walk on any road except where there is no pedestrian signage like on some motorways. To indicate there's no infrastructure for pedestrians we can use sidewalk=no (no footpath alongside the road), shoulder=* (is there a shoulder that may provide some space for pedestrians) or even barrier=guard_rail (though not that helpful unless we can somehow tag if there is space to walk outside the guard rail). |
| 164933461 | 9 months ago | Yeah agreed it was wrong before and at least now it's correct in that it's parseable. I really don't know which is best access=yes or access=no here, so just seeing if you had an opinion. If I'm making a map to show paths which are open to the public vs those closed/private, I'd show this as open since it's mostly open during the daylight hours when you'd expect to find things open. So I might want access=yes to hint this to data consumers as the default, or we could be agnostic and expect all data consumers to support :conditional and make their own decision on the default. On the other hand, I think it's also reasonable for the tags to match what's signposted, if it's signposted as "closed 6:30pm to 6am" you might expect the tag value to match as 18:30-06:00, or if it says "open 6am to 6:30pm" you might expect the tag value to match as 06:00-18:30. This comes up a lot so maybe I could ask for wider community feedback. |
| 164925685 | 9 months ago | but are pedestrians strictly forbidden based on signage or otherwise? or is it just the case of it's not the best idea to walk here? |
| 164933461 | 9 months ago | do you think we should swap the conditional? Some data consumers won't support conditionals, or even if they do they may still default to the non-conditional. In the case of "closed at night", I think it's better to say it's "open, except at night" instead of it's "closed, except during the day". |
| 164933757 | 9 months ago | Thanks. In https://osmlab.github.io/osm-deep-history/#/way/1087666855 AND wasn't what I intended by the ; but I've made changes and think it's correct now. I've also fixed a few values that used "maxstay" in fee:conditional which should be "stay" per fee:conditional=* |
| 164960025 | 9 months ago | || vs |yes| is a matter of style, is there a clear consensus? I prefer |yes| since it's a bit more readable and less error prone in getting the wrong number of lanes. |
| 164793281 | 9 months ago | Based on these comments I've reverted to restore the slipway ways, then added access=private based on the tag's introduced with this change. |
| 164793552 | 9 months ago | correct based on what? What's the signage on the ground say? Also note that previously we had alt_name=Grimwade Road but now both alt_name and name have the same value, which isn't right. Also the short section up near Noggerup was missed. |
| 164839973 | 9 months ago | it should be the lower case tag value building=hospital, but no worries I've fixed it.
|
| 68775056 | 9 months ago | way/443605093/history added Sydney Water as the Zone Substation operator, are you sure that's correct? I would assume it's Ausgrid who operate the substation. |
| 164614938 | 9 months ago | I've made some adjustments in changeset/164659060 in particular moved the name to the building way. Was it intentional to move Budget Avis Car Rental? Or was that accidential? |
| 164543744 | 9 months ago | osm.wiki/Lifecycle_prefix offers some options, `construction` is usually for something being built/repaired, if it's just damaged and repairs haven't started then I'd leave it as one of the "stages of decay" `abandoned` seems to match best, but I don't like how that implies that there's no plan to repair it, something like `damaged` would be okay too. |
| 164538099 | 9 months ago | The tags look good. |
| 164538429 | 9 months ago | "Sea side lane repair. Circulation in both directions on the remaining lane regulated by traffic light." In that case the road is still accessible to traffic both directions, just with delays. Most data consumers expect highway=construction to mean it's undergoing construction and has not yet opened and therefore there is no access, so I wouldn't use the tag in this case, it will break a lot of maps and routers. I realise we don't tag for the rendered, but I think there has to be a better way to mark it as undergoing repairs but still open than just highway=construction. |
| 164271283 | 9 months ago | Ah I see you've done this now. |
| 164271283 | 9 months ago | Technically the restriction=no_u_turn should only be used on signed no u turns, and not as an arbitrary way to place restrictions on the routing, but it is common practice it is widely used as the latter and seems mostly accepted to do this by the community. So I would say in this case to prevent routers trying to u-turn from Ellerton Drive back onto Ellerton Drive where the dual carriageway merges into single it is acceptable to use a no_u_turn relation here, even though it may not be an intersection and even though there is no signage. |
| 164459113 | 9 months ago | hi I'm not sure what you mean by "open plan" but for the 5 units you've mapped if they are sharing a common wall, but next to each other and not on top what you have for the outlines is good, but for the tags I would use building=house + house=terraced per house=* It looks like the unit number 4 is repeated in your mapping though. |
| 164234120 | 10 months ago | no reply so I'll revert this. |
| 164271283 | 10 months ago | The overtaking=no is good, but the restriction=no_u_turn restriction=no_u_turn needs to go on a relation object which has to/from/via members, and not on the way. In JOSM add a new relation, set the tags type=relation + relation=no_u_turn then add the two ways as to/from members and the intersection node which connects both as a via member. |