NAM, EoMCC, and Commute times

[baertooth 330]

I did a quick experiment tonight to test what might be a problem with the NAM, but it the test was small in scope and I'm not sure if I have gotten what I think I've interpeted correct.

First, I'm not sure what they are called, so I'm going to use acronym EoMCC as Edge of Map Commute Connections, which cover any neighborhood connection a resident can access to use for commuting, such as ferries, roads, highways, trains, and monorails.

Ok, what I did was create a four medium tile regional map, flat land, with a lake in the center with a corner in each of the tiles so each map had water access to the other for use of seaports.  In each tile, I quickly created a small city with residential, commercial, industrial, power, garbage collection, seaport, airport, firestation, and mayor's house, but I didn't make any EoMCC's, the seaport and the airport were the only neighborhood connections I used.  I also grew the cities till they were stable, and there was a good balance of taxes, zones, traffic with few dilapidated buildings and no abandonment.

I have the NAM installed with the better path finding plugin.  I also have other plugins but none that affect traffic.

When I checked my commute time, each of the cities were under 25 mins average and one city was just over ten minutes.  I loaded each city and made sure they were running well and paused them.  Next, I loaded each city and made road connections between all of them so the EoMCC's and their roads formed a ring around the lake.  Next I ran the cities for one year each, two years a piece but alternating cities clockwise after one year so I ended up playing each city twice in once a rotation for two rotations so the cities would be in harmony and stable with each other.

Then I checked my commute times and the conditions of my cities and this is what I found.  First, the commute times jumped up to 40-60 mins.  Second, I started to get some abandonment and really increased dilapidation due to commute times.

Checking what might be the problem, I noticed that the residents who lived close to a EoMCC chose to travel to that instead of looking for a job on the same city tile as they were on.  It's as tho the NAM considers the EoMCC as a tile that contains employment when detemining the residents path finding, but doesn't consider the distance traveled on the other side of the EoMCC as part of the path finding equation.  So those residents who travel to the EoMCC could travel a very long way away to find a job even tho there were plenty of jobs on the same city tile (just father away from the residents home than the EoMCC that resident was using to travel to another map).  And the path finding doesn't seem to be as good on the other side of the EoMCC either.  I had residents travel to the farside of the neighbor's map to get a job when there were several jobs closer.

I'm not sure if this the NAM or the path finding engine in SC4 that's causing the problem.  I wasn't able to test this without the NAM installed to see which is doing it.  And I only tested this once so there maybe another reason why this is happening I haven't seen yet.

I'm really tired so I hope you can understand what I'm saying.   I'm not going to be able to devote much time to test this as completely as I would have wanted to before talking about it here, but I wanted to see if the community was interested in figuring out if what I'm seeing means anything and if the NAM needs some work to force a resident to find a job on their home city tile before finding one on another tile.

thx

[Tropod 144]

I haven't read your whole post, but I've got the gist of it. Basically, there's an issue with the game with neighbour connections & commuter routing & it's not something that can be fixed (well Maxis could). Because of some changes the NAM makes, in the Traffic Exemplar, it may highlight the problem more so, but it is ultimately a bug. To help combat this though, I would suggest that any connections made be done nearest to the middle of the edge & that any active connected cities be updated properly.

[tungston 19]

I think the method is flawed, if you start a city that has short comings, the longer they run, the more the defect shows up. When you add the NAM the problems had already started, and continue to get worse as the years pass. Better Path Finding is not a cure all. If the transits aren't laid out properly to start with, they won't improve much with any implement.

I think you would need to make the experiment totally seperate. Two Idenical regions, except for the NAM.

[SC4BOY 20]

Actually if you run exactly the same experiment on exactly the same cities WITHOUT the NAM you will find exactly the same result, but probably with even more abandonment and even longer commutes.. The commute jump is perfectly normal when you make off-city connections .. The SC4 exec considers any EoMCC to be a "job find" There is absolutely no effort by SC4 (has nothing to do with the NAM) to "resolve" EoMCC connections.. it just "lumps them" into a general traffic picture.. each city considers a "city edge" to be a "job found" as far as I can tell. There is no intelligence to it.

Why werent you able to test it without the NAM.. at least a close approximation. I assume you made backups of the city stages as you went through them.. Just rerun each segment without NAM.. you'll find exactly the same or worse result.

All of these topics have been discussed until people are pretty much sick of it by now.. they only focus on the best ways to "circumnavigate the issues individually".. areas such as good traffic flow, good control of flow, etc ..  Most of the definitive testing of these issues occurred in about 2003. The NAM has left it all far behind and it's strength has nothing to do with what you're discussing other than obliquely.

Almost certainly the WRONG way is the old method people used to use of just throwing a lot of inter-city connections around the edges of a gridded city area.. The focus is instead more on traffic flow control and maximum use of that traffic

A couple of decent related threads (other than the NAM doc's of course on its particular use) are

Traffic Basics

Avoiding "commute loops"

I'm sure there are a TON of older stuff.. but you can start here..