Nice work. I made a few updates to help formatting and overall Wiki consistency.

It was mentioned in a different thread (3.8 feedback) that the water layer is only on the NA server. Can anyone confirm or deny that?
If it's true then that should be mentioned on the page.

DwarfLord wrote:

sketch wrote:Still not crazy about the "visually obvious" language, exactly. A river that goes under a road, even if it's not visually obvious (i.e., you'd have to intend to look down into a gulch or whatever to see the water), is still worth mapping. You might wonder what that bridge is for.

The problem is that the river/stream feature, implemented as it is using the Area Place, is way easy to overdo. And it shows up on the map with high contrast. So an editor who isn't painstaking will end up creating a Mississippi that every driver within miles will see on their display, when all that's there is a creekbed with a few puddles in it. That's the pitfall the guidance is intended to prevent.

(Yes, this just happened in my area, which is why I got the bit in my teeth! The editor added a tiny creek that hardly anybody ever sees but on the map it shows as one of the biggest rivers in the greater Bay Area. It's just really hard to map tiny creeks with an Area Place.)

If Waze allowed us to map streams with a non-drivable road line, I'd support mapping stream features even where no water is visible to drivers. But doing so with an Area Place is too awkward and risky unless water itself is "visually obvious".

With Sea/Lake/Pond it is (I hope) less controversial that water should be visually obvious to drivers on nearby roads for there to be a bright blue water feature on the map...?

If this is not persuasive, I'd be happy to see alternative language that could prevent the disaster I mentioned above...!

FYI there is/was a road to river script for this purpose.

Sent using Tapatalk for Android 4.4.2

Could someone remove the "pond" located on the live map:
https://www.waze.com/livemap?lon=-78.45 ... 02&zoom=16

I only see:
https://www.waze.com/editor/?env=usa&lo ... 965&zoom=7
for update requests:
https://www.waze.com/editor/?env=usa&lo ... 965&zoom=4 (closed issue from live map)
https://www.waze.com/editor/?env=usa&lo ... 965&zoom=5

vectorspace wrote: I think there is one clear rule #1. If it is in the Water Layer already, don't map it. Can anyone refute or argue against such a rule? I can't think of a reason.

Perhaps only in places where it might be particularly important to see the name of the body of water on the map, I don't know. I kind of like seeing the names of lakes and rivers on the map.

Still not crazy about the "visually obvious" language, exactly. A river that goes under a road, even if it's not visually obvious (i.e., you'd have to intend to look down into a gulch or whatever to see the water), is still worth mapping. You might wonder what that bridge is for.

In response to Kent... with many water features, we have a huge blob upon which there can be many destinations. I think, as CBenson and DwarfLord mentioned, that Water Area Places for display (on the Client and Live Map, are a different issue than destinations.

I would rather see Point Places put in around water features for destinations because this could accommodate those things already in the Water Layer and those added by Area Places showing the water feature. Of course, there may be variances on such a suggestion.

I think there is one clear rule #1. If it is in the Water Layer already, don't map it. Can anyone refute or argue against such a rule? I can't think of a reason.

In the Wiki we can provide instruction on how to find out -- by looking in the client or looking on Live Map. We can also try to list those things generally available in the water layer and those things that are not usually there.

I think another general rule #2 would be to add water features that provide a visual reference and navigational aid to the map for the client or Live Map. This is consistent with Waze wanting more content. Place the Area Place destination point at a logical location, and if none exists, leave it in the middle.

A general rule #3 would be to add Point Place destinations related to the water feature, particularly if large, at the specific destination points. This might be a portage location, a dock, a place to launch boats, ferry location, etc.

A general rule #4 would be that it is acceptable to add water Point Places for dry channels, those that fill up with water during rains or floods, because they are navigational references. Some of these locations should not be mapped as water when they have dual use. For instance, in New Mexico, where we have little water, we must have flood control areas, basins, that will catch and retain water to avoid damage and also hold the water so it will seep into the ground. These basins are often the locations of parks for a dual use of the space within the city. Do not mark all of this basin space as water, only the parts that are really used all the time for water. Hope that makes sense. There are a lot of this type of thing in the southwest including big cities like Los Angeles.

I will try to think of other draft rules...

sketch wrote:

vectorspace wrote: I think there is one clear rule #1. If it is in the Water Layer already, don't map it. Can anyone refute or argue against such a rule? I can't think of a reason.

Perhaps only in places where it might be particularly important to see the name of the body of water on the map, I don't know. I kind of like seeing the names of lakes and rivers on the map.

Good idea... putting the name down when it does not show is a great reason to do this.

Fallibility of the Waze water layer is a good argument for editors to add such things. The absence of water features and lack of names have already been mentioned in this thread. There's not much we can do about items that should be moved from the water layer... other than mention it to Waze staff.

It seems we have enough to make a draft modification to the Wiki, which we could prototype here. I can take a stab at it unless someone else is interested (please).