News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Station coverage: a proposal

Started by Carl, April 11, 2013, 01:39:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carl

As part of the new walking features, it's recommended that we turn up the station coverage to much higher values than we are used to. As such, it's appropriate to scrutinise how this feature works at higher values.

The most noticeable aspect is that the "square" nature of station coverage is exacerbated at high values. Here's a diagram:



Each square represents an in-game tile. Imagine that the orange dot is a bus stop. If our station_coverage=6, then every square in the diagram will be covered by the stop. If we assume that each square is 100 metres, then we can say that the station's coverage radius should be 600m. And, in line with this, the green dot represents a square which is 600m away from the stop and receives coverage.

But the red dot is also covered by the stop - despite being more like 850m away from the stop, almost 50% more than the supposed coverage of the stop. (The grey circle here represents a 600m radius from the stop). This seems inconsistent.

To make station coverage consistent, it would be better if station coverage were roughly circular -- that it properly respect a consistent radius, so that only the squares touched by the grey circle are covered when station_coverage=6. (I believe this is how coverage works in, for instance, Cities in Motion).

I suspect that this aspect of the code is unchanged from Standard -- and I guess it has never been an important issue before since we've usually used station coverage of 2 or 3. But if we are to use much higher values in Experimental now, it would be interesting to see if we could switch to a more realistic, roughly circular model of station coverage.

Any thoughts?

ӔO

I can't recall where I've seen it, but I do remember that stations don't cover a perfect circle in the real world.

If the station is at an intersection, the coverage will extend X meters along the roads and results in a coverage that looks like a cross or star. This is because foot paths may not always have a direct route to the station and therefore the people have to make detours by following the road.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Sarlock

In a perfect grid of roads it would resemble a diamond shape with jagged edges.  The shape would change according to local road layout/connections.  There is also a statistical drop-off of ridership as you move farther from the station (walking times increase).
It's probably best kept as a square for gameplay reasons, squares fit nicely together to cover an area and are the simplest to understand for players.
Current projects: Pak128 Trees, blender graphics

ӔO

Personally, I like the diamond shape.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Isaac Eiland-Hall

If you want a radical idea that probably would be too complex.... You could seek down road tiles, X number of road tiles from the stop. Each road tile would connect X number of tiles next to it - with a decreasing number the farther away from the station. So maybe it would start at 3 tiles away, then on the 3rd road tile from the stop, it would be 2 tiles away; then at the 5th it would drop to a single tile away from the road.

Does that make sense? :)

The preview would obviously have to show the station coverage in real-time, but... this wouldn't be too hard on CPU I wouldn't think...

jamespetts

One ought to remember that the current release candidates of Experimental - and therefore the next release version - which use this larger station coverage take account of the actual walking time from the origin to the stop. The idea of the coverage area is that it should be sufficiently large to capture the majority of those passengers who would be content to walk to the station in light of their journey time tolerances. The actual work in determining who does in fact walk to the station is done by the walking time itself. The retention of a catchment area (but its substantial enlargement) was simply a way of achieving this aim with minimal changes to the code - that aim would rather be undermined by what would be a rather complicated change to the code to create an intricately shaped coverage area. If a significant number of would-be passengers whose journey time tolerances allow them to walk to the station are excluded by the catchment area, then just enlarge the catchment area: the real radius effect is simulated by the walking time together with journey time tolerances (and, if there are multiple possible modes of transport, the routing system of finding the fastest).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock

So a station of coverage 20 tiles would likely have a similar catchment to a station of 40 tiles because it would probably already be outside their max walking time at 20 tilse?
Current projects: Pak128 Trees, blender graphics

jamespetts

It is slightly more subtle than that - different passengers have different journey time tolerances, and, of course, walking is slow. At 125m/tile, a 40 tile distance would give us 5km, or an hour's walk at the default of 5km/hour. This would be on top of the waiting time, the transfer time (if any) and the journey time of each connexion, and the walking time to the end. Some passengers would indeed be prepared to do this, but a very great many would not. Also, if there were any competing modes of transport (private car, closer stations, etc.), the passengers would be far more likely to choose those.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

sdog

consequence thereof would be that catchment areas ought to be dynamic. For a solitary station in 1900 century 40 tiles would be good. For bus stops in a city, this would cause a huge overlap and way too many pax would have to be considered.


ps.: 125m /tile make plane almost completely pointless, even on the largest of maps. 500 km would require 5000 tiles already.

ӔO

some of the shorter regional flights only have distances of 160km.

The smaller bombardier, avro, embraer and lockheed airplanes are popular with these regional routes.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Sarlock

Quoteps.: 125m /tile make plane almost completely pointless, even on the largest of maps. 500 km would require 5000 tiles already.

Pretty much.  The edges might find air travel feasible to the opposite edges on a large map of 2,000+ tiles or so, but for anything in the interior of the map they would all be within 2-3 hours travel by moderate speed rail and even less with high speed rail (an hour or so).
The flexibility to set scale allows the player to decide whether to create a small regional map or a larger area.  Setting at 250m/tile on the same map would make air travel feasible for longer distances.
If you wanted a map purely to the graphical scale of around 20m/tile, then a 2,000x2,000 map would only be 10km².  Great for doing a detailed model of a single city.

Continued increases in computer hardware size and speed might make maps of 5,000² or larger possible within a few years.  At some point the restriction on maximum map size may have to be increased... although a map that huge would be so huge it would be difficult to manage from a gameplay perspective.  2,000x2,000 is already a massive map.  Perhaps with 40 players.
Current projects: Pak128 Trees, blender graphics

ӔO

one thing that occurred to me.

when pax travel diagonally, is their distance sqrt2 or 1?

also, slightly off topic, but should not diagonal ways also cost 1/sqrt2, instead of half per tile?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Carl

Quote from: jamespetts on April 11, 2013, 11:44:12 PM
One ought to remember that the current release candidates of Experimental - and therefore the next release version - which use this larger station coverage take account of the actual walking time from the origin to the stop. The idea of the coverage area is that it should be sufficiently large to capture the majority of those passengers who would be content to walk to the station in light of their journey time tolerances. The actual work in determining who does in fact walk to the station is done by the walking time itself. The retention of a catchment area (but its substantial enlargement) was simply a way of achieving this aim with minimal changes to the code - that aim would rather be undermined by what would be a rather complicated change to the code to create an intricately shaped coverage area. If a significant number of would-be passengers whose journey time tolerances allow them to walk to the station are excluded by the catchment area, then just enlarge the catchment area: the real radius effect is simulated by the walking time together with journey time tolerances (and, if there are multiple possible modes of transport, the routing system of finding the fastest).

Hi James, thanks for this answer -- that's a very convincing explanation of why it's not worth changing the coverage feature.

Vonjo

CMIIW. It means that the station coverage feature is currently quite "useless". The reason why this feature is still there is because:
1. The feature has already been there, so it is easier to keep it.
2. It is good for the CPU, as it will limit the check to only the area inside the station coverage, instead of the entire map.

So, the optimal station coverage size should be as big as your computer can manage. If your computer works fine with station coverage which covers the entire map, then it is okay.
Am I right?

jamespetts

Quote from: sdog on April 12, 2013, 03:32:17 AM
consequence thereof would be that catchment areas ought to be dynamic. For a solitary station in 1900 century 40 tiles would be good. For bus stops in a city, this would cause a huge overlap and way too many pax would have to be considered.

Why would this overlap be a problem? I think that Vonjo is largely correct when he wrote,

Quote
So, the optimal station coverage size should be as big as your computer can manage.

As to this point:

Quote
ps.: 125m /tile make plane almost completely pointless, even on the largest of maps. 500 km would require 5000 tiles already.

It is possible to make a 16384 x 1024 map, which equates to 2,048km x 128km (or an 8192 x 2048 map - 1,024km x 256km), in respect of both of which air travel is feasible: if a large part of the middle of the map is empty ocean, this will not put a strain on people's computers, as empty map does not significantly add to memory or CPU load. Another idea relating to long distance travel is the portal to foreign destinations: around the map one might have dotted a number of portals to foreign ports/airports with a set of goods demanded/supplied (which might change over time depending on a configuration file, along with passenger demand changing over time), and where convoys can be sent, wherein they approximately simulate a long trip without actually moving (there is a lapse of time; they then load and unload and wait a further time before re-emerging onto the map, where the time is based on the vehicle's maximum speed and the supposed distance to the foreign destination, and during which time maintenance costs are charged in respect of that vehicle; although what to do about long sea voyages that take many real life months: a four month voyage would, at 6 hours per day, take 40 game years).

Quotealso, slightly off topic, but should not diagonal ways also cost 1/sqrt2, instead of half per tile?

Diagonal ways do indeed cost a specific fraction of the cost of a straight tile, based on the actual relationship between the length of a straight and a diagonal.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

wlindley

Sounds like what we need, in addition to a mode like "Hide buildings under cursor" is a mode to "Show actual station coverage, tile-by-tile, with a color gradation based upon walking time"

jamespetts

If anyone would like to program that, let me know!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

o_O

#17
So essentially station catchment area is just a formality and passengers walk to a station (or refuse to) based on time tolorance and walking speed and what not?  So its probably a good idea to have more then 2-3 stops in a city.  That actually makes alot of sense.  In my head I was justifying the large areas by saying "well each stop represents a handful of stops in that general area, or maybe we assume that smaller routes link to player built trunk lines"

I don't think security delays and generally long airport lines are factored into simutrans airtravel.  Without that extra 1-2 hours per trip many shorter routes are viable that would not be with realistic conditions. 

Edit: Oh it actually does have that interesting.  I guess it would still have uses crossing water and nasty terrain, or small regional flights.

Carl

Actually, Experimental has a "minimum airport wait time" parameter to simulate security etc at airports. I believe this is set at 30 mins by default; were I using air travel often in-game, I think I'd set it somewhat higher than this.

neroden

I like the behavior in current experimental, with the "walking time".

...there is one weird result of station coverage in current experimental however.  Built a port on the ocean.  You can stop a ship on *any tile in the ocean* within the station coverage and it counts as "in port".

I don't think this is desirable.  I've had trouble directing ships into depots because the depot is within the station radius.  Is there some way to restrict the places where ships can dock, so that they have to actually be within one square of a dock?

Also, the station coverage radius ends up being very large for freight.  I actually like the idea that freight will get hauled on foot across the street to the factory (or whatever) -- it's been extremely useful -- but it does mean that you need a "walking time" equivalent for the FREIGHT as well as for the passengers and mail, representing how long from the factory to the loading dock.

The way walking is currently handled also gives some odd results in cases where the source and target freight factories are very close, within the radius of a single stop.  You have to build two stops and run trucks between them, but the freight will run in both directions :-).... this freight should be walking, not taking your trucks at all.

jamespetts

Ahh - thank you for pointing out the issue with ships docking: I had not considered this. This is a rather tricky question, actually, as currently the two mechanisms (the docking and the coverage radius) are one and the same, and it seems as though they might well need to be separated. Thoughts as to how I might achieve this separation cleanly and clearly to users would be welcome.

As to freight, however, I have already dealt with this: I have added a separate coverage radius for freight, which can be set separately in simuconf.tab with the line "station_coverage_size_factories=". In the next release of Pak128.Britain-Ex, this will be set to 1, meaning that a freight station will need to be immediately next to a factory in order to receive freight from it (no more hauling tons of coal over hundreds of meters by hand to the station). This reduced coverage is shown when placing a freight station or when holding down CTRL when placing a non-freight station (for example, a mixed passenger/freight stop). This reduced coverage applies only to goods - passengers will walk in their full coverage radius, and likewise people with letters to post.

Indeed, I wonder whether this could be the solution to the first problem - just use the freight station coverage for the ships in port; but would this be enough?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I have modified the code on my Github branch so that ships only dock (and recognise as stops) if they are within the *goods* coverage radius of the port, which is a radius of 1 for Pak128.Britain-Ex. This ought to solve this issue.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

greenling

Hello James i think that a radius from om tile for goodsstations Can make problems with exitens games.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

Greenling,

thank you for your input. The best way to deal with this is to set station_coverage_size_factories in the simuconf.tab of the pakset when loading an old saved game to the same as the station_coverage_size value, or alternatively adjust it to match the station_coverage_size value in the advanced settings window (key "i" in Pak128.Britain-Ex) so that the old saved game will work as before.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

greenling

Hello Jamespetts i have look on the demo.sve out the simutrans exp 9.5 and there some factorys they only with
massiv earthmoving can be reach.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

MCollett

The current situation (Simutrans 112.2 Experimental 11.9005) appears to be that the reduced goods radius only applies for outward goods: inward goods are magically transported to a factory from any stop within the larger passenger radius.  I presume that the intent is for the reduced radius to apply both ways ...

Best wishes,
Matthew

neroden

Quote from: MCollett on April 29, 2013, 07:28:51 AM
The current situation (Simutrans 112.2 Experimental 11.9005) appears to be that the reduced goods radius only applies for outward goods: inward goods are magically transported to a factory from any stop within the larger passenger radius.  I presume that the intent is for the reduced radius to apply both ways ...

Actually, I've tested this quite recently.  The effective radius for freight is as large as the large passenger radius in BOTH directions.  station_coverage_size_factories simply does not work.   The station doesn't think that it's connected to the factory, but it doesn't matter: the goods will come and go anyway.

Now, before you try to fix this:  having the coverage distance for freight too small is not a good idea.  Many "final outcome" factories are only one tile large.  There isn't much room to put freight stops next to them, which will work out rather badly in multiplayer games.

Two possibilities:
(1) Handle freight exactly like passengers.  The stevedores can haul it up from the docks (or whatever), but at a low, time-consuming speed.  I like this idea.    Players who get closer-in stations will have an advantage, but players with further-out stations won't be shut out.

If it's possible to have *different walking times* for different freight, that would be ideal, and could be used to penalize far-out stations quite significantly.  The result does feel a little unrealistic with coal, but more realistic with vegetables, beer, etc.

It should also be easy to code, since you've already done it for passengers and mail.

(2) Increase the coverage distance to 2.  This would require making the freight coverage distance actually work, however, which may be a *lot* harder than it at first appears. 

I strongly advise that, rather than having separate "freight coverage distance", you simply handle the freight the same way as the passengers, with a walking distance.  It's elegant, and it actually makes sense... people do carry freight across roads, through parking lots, and in the old days, across fields.  Furthermore, freight will benefit automatically from any improvements to the "walking" system (for instance, if walking is redone to trace along roads, freight will automatically benefit).  Just use one system.

Of course, you could also do both (have a reduced freight coverage radius *and* measure walking time within that radius).

The docking mechanism should be separated out from the coverage radius in any case, and ships should always be required to actually be directly next to a dock, 1 tile away.  (No going out in rowboats to meet the ship.)

--
Anyway, currently the "freight radius" limit doesn't work at all.  And I wouldn't want it to work with a strict 1 tile coverage limit.  I have some rather nicely constructed games taking advantage of this.  In particular, it makes it significantly more possible to set up docks on rivers and shorelines prior to the availability of suitable canals.  These are usually a few tiles away from the factories, but sometimes not far enough away (only 2 squares, or 3) to actually build a viable trucking line.

jamespetts

Thank you very much for pointing out this bug/these bugs, and for proposing solutions. I should be very interested in: (1) historical precedents for this (information on the historical location of freight sidings, goods yards, canal docks, etc., relative to factories without interconnecting roads, narrow gauge railways, etc.); and (2) other people's views on the question. One possible solution is to have both: a trans-shipment time and a reduced radius (which can be set to 2), which would of course require the fixing of the radius. Nathaneal - do you have any particular reason to suspect that fixing this might be very difficult?

Another issue is how this works with different types of freight. I can see that it makes sense to have stevedores lugging boxes of piece goods, barrels of beer, bundles of planks, etc., down the road by hand - but how on earth would this work for coal, oil, clay, chemicals or livestock? Livestock, I suppose, could be hearded, but coal was generally unloaded by tipping the whole wagon up end so that its contents were deposited on a large pile of coal, in exactly the right place to be shovelled to its intended furnace (the wagons would go up inclines so that they were on top of the pile; these days, hopper wagons just empty the bottoms onto a huge conveyor belt), and oil and chemicals, of course, are unloaded by attaching pipes to the wagons.

As to docking ships, can anyone see any problems or issues if I just require all ships to dock within a single tile of any dock regardless of the freight station radius set in simuconf.tab?

One issue, however, is this: we are quite near now to the release and I do not want if I can possibly help it to increment the saved game version again before release. Having different speeds for hauling different types of freight would do this, as we need a separate simuconf.tab entry for each type (currently, there is a single entry for passengers), each of which has to be saved with the saved game.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

Quote from: jamespetts on April 29, 2013, 11:12:06 AM
Thank you very much for pointing out this bug/these bugs, and for proposing solutions. I should be very interested in: (1) historical precedents for this (information on the historical location of freight sidings, goods yards, canal docks, etc., relative to factories without interconnecting roads, narrow gauge railways, etc.); and (2) other people's views on the question. One possible solution is to have both: a trans-shipment time and a reduced radius (which can be set to 2), which would of course require the fixing of the radius. Nathaneal - do you have any particular reason to suspect that fixing this might be very difficult?
The station coverage radius seems to be used in a *lot* of different places.  That's my only reason for suspecting that this is going to be difficult to fix: tracking down every usage.

QuoteAnother issue is how this works with different types of freight. I can see that it makes sense to have stevedores lugging boxes of piece goods, barrels of beer, bundles of planks, etc., down the road by hand - but how on earth would this work for coal, oil, clay, chemicals or livestock?  Livestock, I suppose, could be hearded, but coal was generally unloaded by tipping the whole wagon up end so that its contents were deposited on a large pile of coal, in exactly the right place to be shovelled to its intended furnace (the wagons would go up inclines so that they were on top of the pile; these days, hopper wagons just empty the bottoms onto a huge conveyor belt), and oil and chemicals, of course, are unloaded by attaching pipes to the wagons.

Historically, for liquids there were often pipelines (often, hidden underground pipelines) running from the docks to the factory.  This is still done.  Pipes under or over a road are particularly common with liquids unloading on the far side of a road from a factory.  Coal is a particular issue, it is certainly usually unloaded VERY close to the destination or even INSIDE the factory, though conveyor belts and miniature railways are two options which were used for dragging it from docks.  Also men with handcarts in very early "selling coal for fires" applications.

Now, the game isn't ever going to be perfectly realistic (for one thing, the roads and houses are 'officially' 125 meters wide by default... and I don't think we'll ever get this down to a realistic 10 meters for roads, and what would we we do for house pictures if we succeeded anyway).

f the *time penalty* for the distance from the source/destination could vary by good, we could get a decent approximation to realistic behavior, even if you have to imagine an "invisible conveyor belt" or "invisible pipeline".  So, for instance, it may only cost 3 minutes for a passenger or mail to travel to the station... but for a haul of coal it should cost 3 hours.  Even for a good which is time-insensitive, this is going to give the advantage to the competitor with the adjacent station.  I think.  I'd have to check on the algorithms there.

QuoteAs to docking ships, can anyone see any problems or issues if I just require all ships to dock within a single tile of any dock regardless of the freight station radius set in simuconf.tab?
*Nathanael listens for other responses*

QuoteOne issue, however, is this: we are quite near now to the release and I do not want if I can possibly help it to increment the saved game version again before release. Having different speeds for hauling different types of freight would do this, as we need a separate simuconf.tab entry for each type (currently, there is a single entry for passengers), each of which has to be saved with the saved game.
The existing situation is tolerable and playable -- give it a whirl -- and you shouldn't worry about it before release.

jamespetts

Would a workable solution be, I wonder, (1) to fix the broken parts; (2) to increase the factory radius to 2; (3) to separate the dock radius and have it fixed at 1; and (4) to introduce a trans-shipment time based on a dispersal speed of 1km/h for all freight?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

#30
Quote from: jamespetts on April 29, 2013, 05:01:22 PM
Would a workable solution be, I wonder, (1) to fix the broken parts; (2) to increase the factory radius to 2; (3) to separate the dock radius and have it fixed at 1; and (4) to introduce a trans-shipment time based on a dispersal speed of 1km/h for all freight?

Sounds fine.

I also had another thought -- make the dispersal speed based on the weight, which already exists.  Passengers and mail are the lightest.  :-)

---
(The idea is that wool weighs 380/70 = 5.5 times as much as passengers, so it should run at 1/5.5 = 0.18 times the speed of passengers.  But thinking about it, this would probably end up being 1 km/h for all freight anyway, so you might as well just go with 1 km/h.)

Junna

Quote from: jamespetts on April 29, 2013, 05:01:22 PM
Would a workable solution be, I wonder, (1) to fix the broken parts; (2) to increase the factory radius to 2; (3) to separate the dock radius and have it fixed at 1; and (4) to introduce a trans-shipment time based on a dispersal speed of 1km/h for all freight?

Would the trans-shipment penalty affect goods changing train at a station too?

jamespetts

Nathaneal - how would that relationship work, exactly? Passengers' speed are based on the actual average walking speed for humans. How can this scale to other goods by weight compared with passengers?

Junna - I think that it would probably have to do so, yes, if it were to be consistent.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

The idea was that wool weighs 380/70 = 5.5 times as much as passengers, so it should run at 1/5.5 = 0.18 times the speed of passengers.  But thinking about it, this would probably end up being 1 km/h -- or LESS -- for all freight anyway, so you might as well just go with 1 km/h.

neroden

FWIW, in real life, freight transshipment at stations is expensive in terms of time -- very time-consuming -- so it's just fine to have such a penalty as far as I am concerned.