b-jazz's Comments
| Changeset | When | Comment |
|---|---|---|
| 183588316 | Your multipolygon changes here are wrong, am I'm trying to fix them up. You added a bunch of things like tees and fairways as "inner" relations to the golf course multi. This effectively says that they are EXCLUDED from the golf course area, which makes no sense. If this is confusing, please let me know. |
|
| 184544110 | Hey there Charles, I cleaned up some errors in this changeset and wanted to let you know about the errors so that you can avoid them in the future. You have set up multipolygon relations between the fairways and greens, and that's just great. But then you took it a step too far and tagged the outer member of those multipolygons as a fairway, which isn't correct. Those tags belong to the relation instead of the outer polygon. This might help explain it: osm.wiki/ID_understanding_golf_course_relations |
|
| 184672518 | When drawing golf course areas (i.e. greens, fairways, bunkers, tees, etc.), please be aware that the ways (lines) used to outline those areas must not cross over each other. Fairway outlines shouldn't cross over greens or bunkers or other fairways for example. Take a look at osm.wiki/File:Golf.png for an example of the "Wrong" way to map a fairway and a green, along with the correct way. There are some cases where a fringe exists around a green and you should draw the fairway outline completely around a green, leaving room for the fringe. Other times, the fairway and green butt up against each other. In that case the fairway and green should share the same nodes at the boundary between the two, and every node at the boundary needs to be shared, leaving no gaps. When drawing these shared nodes, editors like iD (built into openstreetmap.org) will "snap" to an existing node if you get close enough. If you have any questions about golf course mapping, feel free to reach out. Thanks. |
|
| 184621280 | FYI, hole direction matters when you draw the centerline. It should be from the tee to the hole. Thanks. I've fixed the ones here that I've found. |
|
| 184502392 | Be careful not to overlap greens and fairways. It's okay (desired in fact) for them to touch (or share boundary nodes), but they shouldn't cross over each other. Thanks. |
|
| 184033348 | “I was simply placing nodes” That is a misrepresentation of what you were doing. You were placing golf pins where they don’t belong just so that you could get some measurement from that point. You placed a golf pin at the edge of a bunker. I’m sorry to be blunt, but yes, that is an absurdity and is 100% invalid and needs to be deleted. It isn’t something that needs to be discussed. It was wrong. If I were to map out a golf cart path and use a dual carriage highway to do it, that would be equally wrong and valid for immediately removal.
|
|
| 184033348 | Hey David, We've been looking over your collection of changes and found many other cases of bad pin placements as you attempt to place distance markers. I'm asking you politely to go back and remove all of those pins that you've created until you can get buy off from the golf mapping community first. I will escalate this up to the data working group to start imposing time outs if you can't delete these yourself. You're placing pins on the boundaries of water hazards and bunkers which is, sorry for the pun, out of bounds of good mapping. thanks for your timely attention on this matter. |
|
| 182764596 | You're saying a few things that make the hair on the back of my neck stand up. First is that you are developing an app just for you and your buddies to use, but in the process you're making changes that are visible to the entire map using community. You need to be aware that making changes can have a rather large impact on the rest of the community and these changes should be thought of carefully and discussed with the community. Second, you're using A.I. to help with these decisions. I'm not afraid of AI, but I'm fully aware that it is no panacea and doesn't fully understand how the world works and will often steer you in the wrong direction. This is a big red flag. You're talking about recruiting a bunch of others to help apply your design decisions across a large swath of golf courses. You might want to slow things down a bit and get buy off before you go that route. You just started mapping a month ago and now your talking about making some major changes on a large scale. Another red flag. What you might consider is using OSM as a base layer and then adding whatever your heart desires as a layer on top of that. Your changes would exist in your own database layer that you control and manage and you would have the final say in. This would leave the OSM layer unchanged as the vast community needs to rely on something stable and well defined. Another thing to consider for your app is that you could do the front/back of green calculations dynamically. You/AI would write an algorithm that would figure out where the golf=green way intersects with the golf=hole line and generates you a front of green measurement. It could also programmatically extend the golf=hole line through the far side of the golf=green way to determine the back of green distance. You would instantly get the information for every golf course in the world without having to recruit an army of mappers to make questionable edits to the base map in OSM. |
|
| 182764596 | Let's dial it back a bit Hogmite. You start off with 3 false statements in your first sentence. This doesn't strengthen your argument. Let's see if we can achieve some compromise instead of throwing insults around. Your rug beating POI argument doesn't really help your case. I'm assuming there is some community place where you can bring your rug, hang it up and maybe use some shared rug beating implements to get rid of built in dust from your rugs. That is something that should be mapped. I was unable to find anything on the map with that tag. Could you please share it with me? I'd love to check it out. Back to the pins though. I'm not a fan of marking the center of the green as a pin either, but at least that has some history in actual golf course maps from golf courses/clubs/resorts. I don't know the actual numbers, but a quick sampling of maps just now had about 40% of the "hole" lines ending in a pin, while the rest just had a line ending in the middle of the green. To mark the front and backs of a green though with a pin is incorrect as there just isn't a pin there. The logical place to put this data wouldn't be nodes on the map, but instead tags on the golf=hole way. There is already a dist(ance) tag (dist=*) that can be extended to show other information like distance from certain tee colors. You could do something like "dist:front_of_green=123" or "dist:red:front_of_green=123" or something like that. You'll get much less pushback than putting in arbitrary nodes on the map. Is that something you'd be willing to explore? |
|
| 182764596 | There is a basic adage about "mapping truth" or "map what is on the ground". You are putting pins where they don't exist. Never have and never will. The virtual pins marking the front and back of the green shouldn't be mapped and will be removed. It's as absurd as marking every pin placement that has ever existed in a given green. If you want to know the distance to the front of the green, figure it out mathematically and write your own golf mapping app that downloads a course, analyzes the features and can display that. But creating something out of nothing is not the correct thing to do. If you want to challenge this, I'd suggest you bring it up in the various OSM communities (Slack, IRC, mailing lists, Discord, etc.). If you have a problem with me deleting what is arguably wrong, you can approach the data working group and see if you can convince them. So, please follow the particular format that has been established and revise your inputs to align with the standard. Thanks. |
|
| 183906796 | FYI, this action was the wrong thing to do. See this wiki for an explanation: osm.wiki/ID_understanding_golf_course_relations |
|
| 183764772 | Same thing applies to your changes on the 17th hole. |
|
| 183764772 | Hey there Tim, Please be aware that greens and fairways can't overlap like you've made them on the 18th hole in this changes. Please correct this edit. Thx. |
|
| 183762755 | I've reverted most of the changes on this course as they go against best practices outlined in the golf course OSM wiki pages. To bullet point the biggest problems: * lollipops instead of proper multipolygons
|
|
| 183358005 | Hey there Dave. I reverted the 4th hole fairway change you made here as your edits made the fairway and the green intersect with each other. If you reduce nodes, please make sure it doesn't change the way drastically enough to alter its path and start crossing over other gold course elements. Thx. |
|
| 183524810 | FYI, the golf=hole lines need to point from the tee to the green. I've corrected the ones from this batch of edits but wanted you to know in case you do more courses in the future. |
|
| 183423193 | Hey maddog, What's going on with this course? I see fairways like way/1524788582 that are a big mess. Why are these being mapped like this? There are several like this in your most recent edits. |
|
| 183378279 | FYI way/1524477498 crosses over a couple of bunkers. |
|
| 183235763 | Hi Davis, There are a bunch of problems with your course edits and I wanted to point them out so that you can correct your mapping on future projects. 1. You're deleting other people's work. For instance, there are some green outlines that you deleted and then redrew from scratch. You should modify the existing paths unless it is impossible or extremely difficult to do. And if it's the latter, look into better tools like JOSM.
If you have any questions, please let me know. And visit the wiki for all sorts of useful information about mapping golf courses. You can find it at osm.wiki/ |
|
| 183237081 | Thanks Frame, But please make sure you don't intersect golf features. One of your water areas was overlapping a fairway on a golf course. The intersection of the two was declared as both water and grass at the same time. Instead, share the nodes at the boundary and adjust location as appropriate. Thanks. |