GreasyPiePaws wrote: I wholeheartedly agree with setting a road lock standard including bumping the lock level when roads are verified complete. The only thing I would do different is to make Ramps locked at the highest level of whatever it is connected to. For example, I don't think it would make sense for a ramp going from a MH to a mH to be locked at level 5.

I agree here and sorry I didn't even think about this ... let's say then the lock should be based on the maximum lock of the roads connecting. Because there would be no house number addressing, this lock may actually be different than the roads connecting if the roads connecting are not verified to be correct. What do you think?

GreasyPiePaws wrote:Things I think we should address on the wiki page include:
*Adding links to the Functional Class data available from the state (similar to WI or CT)
*Finding and adding links to additional counties GIS maps (similar to WI or CT)

I totally agree ... If you did notice, I started a post asking about map helpers and the reason I actually did is to add the information we gather to the Wiki.

GreasyPiePaws wrote:*Road Name normalization information, like "County Highways = CR-xxx". I don't know if we have official standards for this yet, but if we do the info should probably be on the wiki.

Totally agree ... Here's something you might not know: the state of Minnesota has two different County Highway Systems ..County State-Aid Highways (CSAH) and county roads ... Ultimate issue is CH does not say County Highway, but just wanted to clarify if there should be any definition for the different types of highways

GreasyPiePaws wrote:*City Name normalization, like what to use for the 'City' field. Do we use the cities layer, or the city data from the GIS maps? (I have seen where these don't always match near the edge of cities) When we are outside of a proper city, do we use the township name or 'no city'?
*Perhaps a checklist we can use to determine exactly what it takes to consider a road segment or place 'complete'.

This is a good question. I currently am updating the city lists in Minnesota to properly mark the names of the townships correctly ... this is a very time-consuming process so I am working little by little where I can. I know what you mean though about house numbering and that is a tricky question. For instance, Brooklyn Park by USPS standards uses Minneapolis as the city name, but that seems ridiculous to me. I think this debate would be something that would be deemed area by area as some areas would be fine to use the City name ... some areas may be better off using the township name, other areas would be better using the USPS standard; on the other hand, choosing none should not be used (especially in areas where house numbering is used) as it will be very confusing for a person looking up an address or may alter the results greatly.

GadgetMTS wrote: Consider this paragraph from the Roads Page:
"If a walking trail (even when not connected to any other drivable segment) is closest to the latitude and longitude of the search result, the routing server will route you to the spot on the segment closest to that walking trail."

Consider the inverse: Wazers using the walking / biking path and Waze will corrupt nearby road data if the walking / biking path is not mapped to absorb their location.
Here is something to consider https://www.waze.com/editor/?env=usa&lo ... 981&zoom=5 this is my second home (work) and there are trails mapped all around. I did notice before I put in the parking lot road, it did try to use the trail if I parked in the east side parking lot, but have never noticed any issues since. I work for Verizon Wireless and many employees use these walking trails for exercise (we even have fun runs twice a year) so plenty of phones could cause issues here, I suppose, if the trails were not present.

On the flip side https://www.waze.com/editor/?env=usa&lo ... s=65177391 should not be there at all and I will eventually delete it after this debate is over ... I drive this area all the time and have never been directed on the sidewalk and this has been on the map for years.

GadgetMTS wrote: Airport Runways are locked "high", but it does not address the Place Area over the airport. Lock at the same level?

I'd personally say the same level simply because it is a place that isn't going anywhere soon and a place that many people need directions to ... this information should only be set to being correct.

GadgetMTS wrote: The /Test wiki page is now resident on the main landing page. Go forth and populate it MN!

I noticed that

GreasyPiePaws wrote: Based on the example, I would start with the ramp locked at 3 because it is attached to Hwy 36. If Stillwater Blvd is verified to be correct, it wouldn't affect the lock on the ramp because now it would be between two roads both locked at 3. Once Hwy 36 is verified complete and the lock on it is bumped to 4, I would raise the lock on the ramp up to 4 also.

That sounds good

GreasyPiePaws wrote:I did not know that there are two county highway systems. We may be in luck though... WI just finalized their name normalization and voted to go with CH-xxx for county highways. So maybe CH-xxx will start to be pronounced correctly soon.

That would be kool actually. Currently, it just says the letters

GreasyPiePaws wrote:What do you think about MN-### for state highways? The signs I see everywhere say 'Minnesota' on them.

For roads without house numbering (or split roads where the house number has to be done a little different) I say go for it. It looks better and sounds better; however, areas that are affected by house numbering should have the road to match the name for house numbering.
Currently though, all ramps should be switched to MN-xxx and highways such as MN-100 should be just the MN-xxx

GreasyPiePaws wrote: All of the forum debates I have seen so far seem to pretty quickly crush the idea of using USPS city names. I have seen using Census Designated Places as city names proposed in other forums, but haven't been able to determine if there is a popular opinion or not. I think that the work you are doing to get the township names straightened out will help make this an easier decision. For what it is worth, I use the city layer in WME to determine the city when naming roads in WI, unless the layer lines are all wonky near the edges then I use the GIS map to find the real edge. At the very least this should help make updates easier if 'correct' changes at a later date (at least that's what I keep telling myself ).

One thing I need to test is to see how addressing works comparing the navigation to a township name to the USPS standard. I personally don't like the idea of the USPS standard because there are way too many variables and it can cause smudged cities if we don't do it right. There are, however, points that seem to make it work such as an outer rim of a city. Here's an example: https://www.waze.com/editor/?env=usa&lo ... s=25311111 I choose this because this is where I am working today (this who city is ugly, and I'm trying to fix it since it seems we have no one editing this area at all) ... anyway, this is Bancroft Twp, yet anyone and their mother thinks of this as Albert Lea. This would be an area that I am almost kool with the idea of using the city name as long as we plan it well so we don't have smudged cities. On the other hand, https://www.waze.com/editor/?env=usa&lo ... s=84297934 this is an area where USPS standards is Albert Lea, but everyone would be under the assumption that Albert Lea would stop at the interstate. I don't know if we should focus more on Residential Place Points for this area so we could search both township name and USPS name, but I have not tested that idea at all to see what issues that would cause.

GreasyPiePaws wrote: Agreed, lock the area to whatever the runways are locked to.

Would you agree that Major Airports (MSP, Rochester, Duluth, Saint Cloud, etc) should be a 5
Secondary airports (Flying cloud, Blaine, Crystal, Saint Paul) Should be a 4
And all other airports locked to a 3?

toolmanzwief wrote:If a person is abusing Waze by walking with the app open, shouldn't their speed data be negated by other drivers who are actually driving? Unless that type of abuse becomes widespread, I don't anticipate this type of problem becoming an issue.

It wouldn't actually be a person abusing Waze. In the case around my work, let's a person there uses Waze to direct him or her to work and after he or she arrives, the app isn't closed (just hits the home button so the app is still running in the background). If this happens often enough, or by multiple users, Waze will create an auto alert stating that GSP trails indicate a road should be present at this location.

The other thing to really consider here is the fact that the reason Waze is not set to be able to be used by pedestrians or bikers (such as Google Maps or VZ Navigator) is because of the lack of trails created. Same reason why Waze currently is awful for truckers to use ... it is not well set up yet to allow for the differentiation of road types. The more we correct FC everywhere, the more it could be looked at a tool for truckers much the same as the more we correctly add trails the more we could be the app for people not in cars

psubrian wrote:
Why aren't those walking trails set to elevation level -5? My understanding was that this is a best practice for walking trails to help avoid conflict with roads.

I think you are right about setting the elevation to -5 ... my big point here is there are a lot of trails mapped all around my city and they are not affecting the navigations at all even though they are not all set correctly.

I did recently delete a lot, not because they were causing navigational issues, but because they looked bad on the map ... but these were for sidewalks between buildings and not trails

I brought up lock standards in the GP Chat group, and it seems like in this region we are doing good with the locks on the page ... although they were confused at first with the second lock levels if house numbering and name is correct. I will discuss this further.

I have been looking at other states for UR policy ... I do believe we need to adopt this. I also believe it may be a good idea to mention in the UR report on how to reset the cached area of map after resolving an issue. I like the 1/4/8 day policy actually; however, sometimes to me that may not be good timing as much of the time we are not getting to the UR within the first 24 hours. I could see more benefit in First day responding to the UR, 6th day, and 10th day and here is why .... some of our reporters may be very busy people and may not realize it isn't obvious to us of what is being reported ... giving a full 10 days seems fair to me to give this user time to explain him or her self. But what do you all think?

BTW, the following sections are finished thus far

https://wiki.waze.com/wiki/Minnesota/Special_roads (although I may bring to the main page to avoid a separate page that may not get noticed)
https://wiki.waze.com/wiki/Minnesota#Cameras
https://wiki.waze.com/wiki/Minnesota#To_do_list (I just moved this to the main page so it may take a moment to show up)
https://wiki.waze.com/wiki/Minnesota#Community

Here's an idea for the User Report Policy:

We have a 1, 6, and 10-day policy

First day we respond, we will say something like "Thank you for reporting an [general error] through the Waze app. The report was not clear on what exactly happened at this location. Could you please explain the issue the occurred further?"

If no responses occur, on the 6th day we will submit another response, "We apologize that we have not heard back from you to explain the issue further. We will need a response to fix the issue further. This ticket will be closed in 4 days if no response occurs."

On the tenth day, we then close the report; however, we will still submit a response, "We apologize that we still have not heard back from you about the issue. We have not found the issue and it could be that maybe your map is giving you incorrect information. Please go to the Waze App, go to Settings, Advanced Settings, Data Transfer, and then Refresh area of my map to see if that improves anything. Due to no response, we are closing this ticket. You can submit another report if the issue is still present."

If the user responds at any time before the issue is closed, we restart the 6 and 10-day policy after we respond to this message (not from the date the user responds).

psubrian wrote:I'm okay with the proposed UR Policy. I personally have always been waiting a minimum of 14 days, only because I know I myself wasn't using the app on a daily basis and sometimes I wouldn't pay attention if I was vacation or any other number of reasons to not pay attention to my phone. 10 days is better than 7.

This is exactly why I don't like the 7-day scenario either ... If you all like 14, we can opt for that instead. I want to be fair to the reporters as well as us