CBenson wrote:...giving correct directions into the station and back to the highway...

This is a huge reason supporting mapping at least the main road of a parking lot. There have been many times when I am in a downtown San Jose parking lot that is not mapped, and when I ask to go home or somewhere else, the navigation snaps me to a road that I may or may not be able to reach from that point. It is hard to get my bearings with no street names in the middle of roads, so I end up exiting on the wrong side going the wrong way. With the main parking lot line I can get the proper navigation.

CBenson wrote:There is no link that I can discern. This makes no sense to me. I don't understand why we need to maintain two separate databases that contain critical overlapping information (stop/target points for all addressed destinations that are not homes) but have different properties (how stop/target points are controlled). This will make troubleshooting routing problems at least twice as difficult as it would be if a route used the same destination point irregardless of whether the user enters an address or a POI name.

+1

I recommend the follow adjustments to [[Places]]

• Intro sentence: Add something like the following for people not following this thread: "Places has replaced the previously used Landmark system in WME."
• Parking Lot section: It is filled with "Landmark" references that I think can be directly converted to "Place" references.
• Image formatting: See http://wiki.waze.com/wiki/Places/Revision. You can cut and paste this page to the main page or just pick and chose the changes. Some are visually difficult to discern, but provides a bit more consistency on pages.

vectorspace wrote:I just learned something about Place-Areas that I didn't know before, or might be a new behavior... not sure.

I was editing something I created in Feb 2012 to bring it up to standards on "landmarks" when I received a save error. OrbitC helped me figure out what it was...

You cannot have two identically named Area Places that overlap, otherwise saving throws an error in WME. I am not saying that is bad, it just is. Some WIKI page might want to document that.

I believe I have captured the two possible solutions on this one error in the Wiki here.

I also changed it to Places from Landmarks. If any adjustments are needed I am happy to make changes.

Whatever the text instructions turn out to be, we really need a couple of visual example of the text in action to prevent ambiguity.

Can we define / standardize what is to be in the "description" field (and update the Wiki Page accordingly)?

Is that information displayed on the app or is it just internal?

Questions:
I assume that the City field in Places should match the one that's used for the surrounding road segments?
And what should be done with gas stations, for now? They were imported by default as Areas, like everything else, and the wiki page now indicates indecision.

qwaletee wrote: I would think that hasn't been dropped in the new scheme, since it appears that places are stored exactly like landmarks were in the database, with some additional columns to represent the arrival point and expanded indicative infomration.

Yes, when I was trying to type in the mailing-address City it didn't pop up because it wasn't the ones adjacent to this spot. That kinda suggests to me it's meant to function the way street segments do.

AND: Is the disagreement over gas stations (Point vs. Area) because of concern over how it will affect the third-party pricing connection?

Hello all!
Prompt when places will appear in the WME in Russia?

Should we start updating each state's wiki? For example in PA:

From: Landmarks in Pennsylvania should follow the guidelines for Connecticut until the national standard is complete.

To: Pennsylvania should follow the Places Wiki for guidance in regards to mapping Points of Interest & Businesses.