• Welcome to SC4 Devotion Forum Archives.

Problem with Commuters

Started by xxdita, December 11, 2009, 07:58:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

xxdita

I started using SimZ with my testing of CAM 2.0 and I have a strange issue, maybe you can help?

I have 2 tiles connected only via rail, going about 8 tiles into either city, with a Maxis freight station at either end. I'll reiterate, no road connections, no avenue connections, no highways... no airports, seaports... only rail, to move the freight out.

But according to the Census Repository, both cities have roughly 2,000 commuters coming in. Any ideas on how to deal with the hobos?

xxdita

#1
Quote from: ldog on December 11, 2009, 08:13:12 PM
Seriously though, wow. Are we sure the census repository isn't misreporting?

Not likely, but anything's possible I guess?


QuoteWhat are the freight counts by the way? Maybe it counts freight as commuters?

Quote from: z on December 11, 2009, 08:38:41 PM
@xxdita: Freight train stations aren't supposed to allow passengers.  Have you verified with the route query tool that your commuters are actually coming in on the trains?  I understand that there's nowhere else that they could come from, but this is SC4...

Freight counts? Hmmm... According to the Station in city 1, 675, according to the neighbor connection 720, with only freight going back & forth, no Sims.

And I was wrong in the actual number of Commuters... it's now over 8,000.




z

Quote from: xxdita on December 11, 2009, 08:44:08 PM
Freight counts? Hmmm... According to the Station in city 1, 675, according to the neighbor connection 720, with only freight going back & forth, no Sims.

If there are no Sims getting on or off at the station (which there shouldn't be), and there are no other network connections to the other city, then I can't see how this could be a traffic simulator problem.  I'd suspect the Census Repository data at this point.  I assume it's coming from an in-game variable, so that would imply that the variable isn't being updated properly.

What happens if you break the rail link between the two cities?

wouanagaine

IIRC, but RippleJet might correct me, the commuters in the Census repository is just an extrapolation, not a real game value

New Horizons Productions
Berethor ♦ beskhu3epnm ♦ blade2k5 ♦ dmscopio ♦ dedgren ♦ emilin ♦ Ennedi ♦ Heblem ♦ jplumbley
M4346 ♦ moganite ♦ Papab2000 ♦ Shadow Assassin ♦ Tarkus ♦ wouanagaine
Divide wouanagaine by zero and you will in fact get one...one bad-ass that is - Alek King of SC4

RippleJet

The "commuters" as reported in the Census Repository is extrapolated demand.
Consider you've had a city growing where there are more jobs than workforce...
That difference would be extrapolated to the region and would in the Census be shown as "Commuters from SimNation".

At this point, the pathfinders know nothing about the extrapolated demand.
It's only when you go to your neighbouring cities that this demand can be fulfilled.

In that neighbouring city the residential demand would be growing.
However, if that city at the same time also allows commercials and industrials to grow,
all those new residents may not commute to the first city at all.
The pathfinder may find jobs for them in this city, or elsewhere in the region...
At the same time this second city will also be extrapolating more demand to the region...

All these extrapolations are counted once a month,
and are only counting the additional demand for that particular month.

These monthly additions to the extrapolations are never negative...
Thus, if demand has once beeen extrapolated, it will always be there.
Hence, the reason why it's impossible to break an eternal commuters loop.

The Census Repository adds all these demands throughout the lifespan of the region.
Thus, it cannot know whether and how these extrapolations have actually been fulfilled.

To what extent the pathfinders actually know about all these extrapolations, I do not know...

z

Tage, I think your description explains what's going on here.

Before the pathfinder runs, it needs a destination, which is where the destination finder comes in.  The destination finder sees the extrapolated demand from the neighboring city; this is an important part of how routes to neighboring cities are chosen.  However, at a minimum, the destination finder would check to make sure that a neighbor connection exists.  If one doesn't, the destination finder does not consider the other city a suitable destination, and will look elsewhere.  So the destination finder sees the extrapolated demand, but is smart enough in this instance not to point the pathfinder to someplace where it can't reach.  (If it did, you'd get residences abandoned due to commute time; this is technically correct, since the commute time would be infinite.)  The pathfinder itself knows nothing about demand, extrapolated or otherwise; it just constructs a path to whatever point the destination finder has given it.  At least it tries to do so; once again, if it can't, you get abandonment due to commute time.

So the "commuters" don't really exist, and the traffic simulator doesn't think they do, either.

xxdita

#6
I think it's obvious by the looking at the paths, and the neighbor connections, that there are some true commuters, Sims that leave their hometown looking for work. Otherwise the traffic sim wouldn't consider a neighbor connection as a viable destination. The problem is that once a Sim leaves the tile, he is for all intensive purposes gainfully employed. The traffic sim doesn't care where, because it's only for one city at a time, not truly Regional.
Whereas the excess demand is constantly passed along to the next connected city tile you open, not just the one right next door.
However, in the neighboring city, those commuters seem to start their trip from 0, having paid no penalty for crossing over the border. So if there are no available jobs close to that connection, and another neighbor connection is within range, it is possible for these commuters to keep travelling, creating the "eternal commuters" problem. Although I'm fairly convinced that the eternal commuters is actually just the extrapolation itself. And the only way to avoid extrapolation is to have either negative or zero demand every time you were to exit & save a city.

RippleJet

I've discussed this a bit with Nate... and he suggested to build a "toll booth" or similar ("welcoming sign") at every border crossing.
The toll booth wouldn't have to collect money, but it would add an entry cost corresponding to the time it would take to traverse half the city they are placed in...
This would reduce the attractiveness of jobs in neighbouring cities, and also reduce the risk of eternal commuters.
It's a pity there's no property setting the entry cost for neighour connnections...


Quote from: xxdita on December 12, 2009, 05:01:26 AM
And the only way to avoid extrapolation is to have either negative or zero demand every time you were to exit & save a city.

The only way to avoid extrapolation is to build no border crossings at all... ::)

SC4BOY

Quote from: RippleJet on December 12, 2009, 05:19:50 AM
It's a pity there's no property setting the entry cost for neighour connnections...

Hmm.. I thought the entry cost was 1/2 the distance across the adjacent city tile at the crossing. I assume this is given the transport mode existing at the crossover (ie road, highway, etc). Is that wrong? Is the entry cost in fact 0?

z

Quote from: xxdita on December 12, 2009, 05:01:26 AM
I think it's obvious by the looking at the paths, and the neighbor connections, that there are some true commuters...

Definitely.  Just to clarify, when I said, "So the "commuters" don't really exist..", I was only referring to your particular situation, where there were no neighbor connections other than the freight rail.

Quote from: SC4BOY on December 12, 2009, 01:10:38 PM
Hmm.. I thought the entry cost was 1/2 the distance across the adjacent city tile at the crossing. I assume this is given the transport mode existing at the crossover (ie road, highway, etc). Is that wrong? Is the entry cost in fact 0?

Yes, as Nate said, "The problem is that once a Sim leaves the tile, he is for all intensive purposes gainfully employed."  So the entry cost in fact 0.

RippleJet

Quote from: SC4BOY on December 12, 2009, 01:10:38 PM
I thought the entry cost was 1/2 the distance across the adjacent city tile at the crossing.

That's what we wish it would be...
However, if that were the case, we wouldn't be having such problems with eternal commuters...

z

#11
More bad news, I'm afraid.

Quote from: RippleJet on December 12, 2009, 05:19:50 AM
I've discussed this a bit with Nate... and he suggested to build a "toll booth" or similar ("welcoming sign") at every border crossing.
The toll booth wouldn't have to collect money, but it would add an entry cost corresponding to the time it would take to traverse half the city they are placed in...
This would reduce the attractiveness of jobs in neighbouring cities, and also reduce the risk of eternal commuters.

Based on the way the traffic simulator works, I don't think this would succeed.  The destination finder is what decides that Sims should cross over into the next tile, and it doesn't take into account costs of specific routes when it makes that decision; otherwise, it would be doing the pathfinder's work.  By the time the pathfinder comes along and computes the costs of the various routes, the decision to cross into the next tile has already been made.

Lenny's experience supports this conclusion:

Quote from: ldog on December 12, 2009, 10:01:02 AM
I use tollbooths on all of my city connections; freight has to get out so even the 0.2 TSEC is not enough deterrent to them and the revenue helps  :D

RippleJet

That does indeed make sense, Steve! :(

SC4BOY

It seems to me that the "destination finder" in some fashion works purely on "as the crow flies" distance, independent of actual paths. Then it may be cancelled later (or altered somehow) if the pathfinder can't satisfactorily get to that selected destination. The path to the "selected destination" can very often be very circuitous indeed as shown by the "route query" later (assuming it succeeds) Sorry to diverge from the "boundry case" but since we were talking about the "selector"... How it sorts out "possible targets to be selected" I don't know.

xxdita

I concur, and I think it would be worth more testing of the kind of tollbooths RippleJet mentioned earlier.

z

Quote from: SC4BOY on December 12, 2009, 08:00:39 PM
Then it may be cancelled later (or altered somehow) if the pathfinder can't satisfactorily get to that selected destination.

No, what happens is that the pathfinding simply fails.  If this happens for enough residents of a given building, the building is abandoned due to commute time.  That's why we can get this type of abandonment even when using perfect pathfinding and there are appropriate jobs within commuting distance.  If the destination finder were given multiple chances, it would find those jobs.

Quote from: xxdita on December 12, 2009, 08:18:17 PM
I concur, and I think it would be worth more testing of the kind of tollbooths RippleJet mentioned earlier.

Sometime in the next few days, I'll be publishing the details of what I've found out about how the destination finder works.  You might want to wait until then.  Or not...

xxdita

I'm not in a hurry to mod the tollbooths just yet...

z

After thinking about it, it seemed to me that I could address this case more specifically here than in my coming post.  So, going back to SC4BOY's original point:

Quote from: SC4BOY on December 12, 2009, 08:00:39 PM
It seems to me that the "destination finder" in some fashion works purely on "as the crow flies" distance, independent of actual paths. Then it may be cancelled later (or altered somehow) if the pathfinder can't satisfactorily get to that selected destination.

Yes, it does work by direct distance, although almost definitely by Manhattan rather than Euclidean distance.  But think about what's meant by "satisfactory" here.  How would the simulator know?  All it sees is that the destination finder found a destination, and the pathfinder found a successful path to that destination.  That's success from its point of view.  The simulator doesn't know if the pathfinder had to go through circuitous routes, a lot of congested traffic, or even toll booths.  As long as the pathfinding succeeded, why should it care?  The alternative is for it to do destination finding for many different destinations, and then do pathfinding on each one of them.  But that's a whole lot more expensive, and it doesn't result in any advantage from its point of view.  Furthermore, there's already direct evidence that it doesn't do anything like that.  From an earlier post of mine:

Quote from: z on November 24, 2009, 08:43:15 PM
In my Chicago region, I had a very bad eternal commuter loop.  Sims would enter the Downtown city at one corner, travel just a dozen squares or so, and exit into the next city.  Meanwhile, in the middle of my large Downtown tile, there were all these large office buildings standing vacant.  So I tried to get the Sims to go to them instead.  I cut all the connections between the incoming city and Downtown except for the one heavily used subway line, and then made that turn toward the middle of the tile.  I removed stations along the way, so that the Sims had to stay on the subway.  But when they finally emerged, they'd turn around and find some way to get back to the original crossing point into the third city.  I extended this "express subway" until it was at the edge of the central business district, but it made no difference; the Sims still turned around and headed out of the city.

There were many, many closer destinations in terms of travel time and distance than the one the simulator picked in this case, which was the crossing into the third city.  But the one that the destination finder picked was the closest one to the trip's starting point, and it stuck with it.  Furthermore, the pathfinder was quite happy to build a path to that point, even though the path essentially looped back on itself (although not using the exact same tiles and networks).

So that's why I believe in the model of the destination finder that I've been describing, although as I said, I will be explaining further details of this model later.  But I can't think of any other model that would explain the behavior I observed in my Downtown city, or in various other places as well.

SC4BOY

Quote from: z on December 13, 2009, 12:05:32 AM
There were many, many closer destinations in terms of travel time and distance than the one the simulator picked in this case, which was the crossing into the third city.  But the one that the destination finder picked was the closest one to the trip's starting point, and it stuck with it.  Furthermore, the pathfinder was quite happy to build a path to that point, even though the path essentially looped back on itself (although not using the exact same tiles and networks).

Ahh but this would be two destination/path processes. As we've discussed before once the path exits the city tile it was "successful". The path to the 3rd city was a whole different destination/path process totally unrelated to the first.

RippleJet

#19
From what I've seen in a couple of my cities, the destination finder works from the west to the east,
probably picking the tracts (which are 4×4 tiles) in consequtive order, starting in the northwest corner,
going down south, and then up to the next column of tracts.

In one of the cities there was on purpose only one road
from the residential area to the commercials and industries,
so that congestion was a inevitable and everybody couldn't use them to reach their jobs, due to congestion.

Unemployment always started in the southeast corner of the residential area:


This became even more obvious in Dublin, a large industrial city where I've been testing seaports.
I bulldozed the neighbour connections, before plopping a seaport on the eastern shoreline.
It took more than a year before the pathfinder started to reroute the freight routes.
When it did, it started with the western-most industries, those being located farthest away from the seaport.



When the western half of the industry had found the seaport, it became overcrowded and upgraded.
After that the western half of the remaining industrial district found the seaport before the next upgrade.
Not until the third upgrade did the industries located closest to the seaport manage to get their freight exported.

If I'm not mistaken, this might have some implications on e.g. sumwonyuno's Capitalis,
where, if I recall correctly, the main stretch of cities was west to east.