[steved]

All of that info is available in TSRE's navi window.
 navi.jpg (26.72K)
Number of downloads: 0

Randy

[Yaroslav23783276]

steved, on 05 September 2024 - 05:49 AM, said:

All of that info is available in TSRE's navi window.
navi.jpg

Randy

So...
These 2 parameters are W_TILE_X_NUMER and W_TILE_Z_NUMER ?
 Скриншот 05-09-2024 223950.jpg (16.51K)
Number of downloads: 0
And where to take x_coordinate and z_coordinate ?

[steved]

The pointer numbers are the coordinates within the tile.
If you are looking for geo coordinates so you can download maps you'll want to use the lat and lon at the bottom of the navi window.
What are you trying to do? That might help.

Randy

[Yaroslav23783276]

I need to make a TsreGeoProjection, I need to figure out where to get: x_coordinate and z_coordinate

Cruiser_38

[eric from trainsim]

You've been given the answer --- from the Navi window, you multiply the tile location by 2048

-2311 * 2048 = -4732928 (X)
14963 * 2048 = 30644224 (Z)

That will shift the center of the world projection by -4732.928 KM and 30644.224 KM

If you want the extra ~1 km in accuracy, you can also add or subtract the X / Y position values within tile -2311 + 14963, but there's really not much of a need for that much precision. The center of the tile should suffice.

[Yaroslav23783276]

Weter, on 05 September 2024 - 11:34 AM, said:

See there

Thank you very much!

[Weter]

You're welcome.

[PerryPlatypus]

Still drives me bananas that here we are in 2024, 23 years since MSTS was released and we still have not achieved the ability to have a decent map projection that isn't skewed to heck AND be able to import high resolution DEM (1/3rd arc, 1/9th arc, 1 meter, etc.) terrain *at the same time*. I never would have imagined that.

Is it possible that some of the coding from QGIS could get ported over into TSRE to allow for expanded flexibility on map projections and especially DEM file format importing? I know QGIS is fully open source, and I'm sure it's FAR from easy to transfer over, but it may at least help with some of the really math-heavy parts of the complexity? Just a thought.

[Weter]

Hello.
Since Globe is sphere, there's no way to put it's surface on flat without distortions at all.
So, for every geographic location's type (latitude especially), some projection gives better results (still not perfect), than others.

[PerryPlatypus]

I'm well aware of the basics of map projections, we use them on a daily basis at my job (designing real world railroad track alignments). Goku was able to develop a good solution to greatly diminish skew using custom local projections, the problem is that TSRE can't import anything besides SRTM DEM terrain data, which is incredibly low resolution, and DEMEX is not compatible with the TSRE projections.

The DEMEX beta version has an ability to use its own system of local projections, but it is completely different than the way TSRE does so, so creating a route using DEMEX's local projection causes TSRE's aerial image map overlay function to completely break, and the map overlays are pretty much a must-have for doing accurate route work, imo.

QGIS has the ability to convert a TON of different DEMs between all sorts of different file formats and projections, but I've never found a way to get them into a format that TSRE can import, I always end up having to rely on DEMEX if I want anything better than the SRTM DEMs.

Clearly we've had talent pool in the train simming community that knows how to work these different things out individually, but until we can have these folks (and the ORTS management team) all come together and get on the same page to implement these all in an integrated user-friendly way, we'll get nowhere.

It's just another thing on the list of shortcomings that discourages 3rd party development for this platform, and thus it is another contributor to this platform dying a long, slow death.

Sorry for the morbidity :) Just telling it like I see it

[Weter]

At least, we have some hopes now - when Eric have lead TSRE's further development.
Or we can wait for ORTS own route creation tool...
Thanks for clarification - I see now.

[eric from trainsim]

A new terrain engine would be idea, but that really should be part of an integrated editor that shares the same source code.

I'm happy to keep fixing little things here and there where it's easy enough to figure out with no real documentation, but won't be touching terrain on my own. There are only a few people who know how to make that work, and one of them is persona non grata to this and my community, and Goku is one of the others and wants nothing to do with further improvements.

If someone who understands how to build the data structure for terrain is willing to take a stab at the math to do something with higher resolution, I'll gladly do what I can to help fold that into TSRE.

[dajones]

I suspect that QGIS uses GDAL to read elevation raster files. I recently wrote some code that uses GDAL to populate the elevation data for a route I'm building. Here is part of my code:

#include <gdal/gdal.h>

float getElevation(double lat, double lng, float* elevData,
  int xSize, int ySize, double* transform)
{
	double x= (lng-transform[0])/transform[1]-.5;
	double y= (lat-transform[3])/transform[5]-.5;
	if (x<0 || y<0 || x>=xSize-1 || y>=ySize-1) {
//		fprintf(stderr,"out of range %f %f %f %f\n",x,y,lat,lng);
		return -1;
	}
	int x0= (int)floor(x);
	int y0= (int)floor(y);
	int x1= x0+1;
	int y1= y0+1;
	double xa= x-x0;
	double ya= y-y0;
	float a00= elevData[x0+y0*xSize];
	float a01= elevData[x1+y0*xSize];
	float a10= elevData[x0+y1*xSize];
	float a11= elevData[x1+y1*xSize];
	return (1-ya)*((1-xa)*a00+xa*a01) + ya*((1-xa)*a10+xa*a11);
}

void saveTerrain()
{
	GDALAllRegister();
	GDALDatasetH rasterData= GDALOpen(rasterFile.c_str(),GA_ReadOnly);
	if (rasterData == NULL)
		throw "cannot read raster file";
	int xSize= GDALGetRasterXSize(rasterData);
	int ySize= GDALGetRasterYSize(rasterData);
	fprintf(stderr,"size %d %d %d\n",xSize,ySize,
	  GDALGetRasterCount(rasterData));
	double transform[6];
	GDALGetGeoTransform(rasterData,transform);
	fprintf(stderr,"transform");
	for (int i=0; i<6; i++)
		fprintf(stderr," %f",transform[i]);
	fprintf(stderr,"\n");
	GDALRasterBandH band= GDALGetRasterBand(rasterData,1);
	fprintf(stderr,"band size %d\n",GDALGetRasterBandXSize(band));
	float* elevData= (float*) malloc(xSize*ySize*sizeof(float));
	if (elevData == NULL)
		throw "cannot allocate memory";
	if (GDALRasterIO(band,GF_Read,0,0,xSize,ySize,elevData,xSize,ySize,
	  GDT_Float32,0,0))
		throw "cannot read elevData\n";
	for (MSTSRoute::TileMap::iterator i=mstsRoute->tileMap.begin();
	  i!=mstsRoute->tileMap.end(); ++i) {
		MSTSRoute::Tile* t= i->second;
		fprintf(stderr,"tile %d %d %f %f %f\n",
		  t->x,t->z,t->floor,t->scale,t->floor+65535*t->scale);
		mstsRoute->readTerrain(t);
		float x0= 2048*(t->x-mstsRoute->centerTX);
		float z0= 2048*(t->z-mstsRoute->centerTZ);
		fprintf(stderr," %f %f\n",x0,z0);
		float minA= 1e10;
		float maxA= 0;
		for (int j=0; j<256; j++) {
			for (int k=0; k<256; k++) {
				double x= x0+8*(k-128);
				double z= z0+8*(128-j);
				double lng,lat;
				xy2ll(x,z,&lat,&lng);
				float a= getElevation(lat,lng,
				  elevData,xSize,ySize,transform);
#if 0
				if (j%128==0 && k%128==0)
					fprintf(stderr,
					  "ll %d %d %d %d %f %f %f %f %f\n",
					  t->x,t->z,j,k,lat,lng,a,
					  (lng-transform[0])/transform[1]-.5,
					  (lat-transform[3])/transform[5]-.5);
#endif
				if (a < 0)
					a= 0;
				if (minA > a)
					minA= a;
				if (maxA < a)
					maxA= a;
			}
		}
		fprintf(stderr,"minmax %f %f\n",minA,maxA);
		saveFloorScale(t,minA-1,(maxA-minA+2)/65535);
		for (int j=0; j<256; j++) {
			for (int k=0; k<256; k++) {
				double x= x0+8*(k-128);
				double z= z0+8*(128-j);
				double lng,lat;
				xy2ll(x,z,&lat,&lng);
				float a= getElevation(lat,lng,
				  elevData,xSize,ySize,transform);
				if (a < 0)
					a= 0;
				t->terrain->y[j][k]= a<t->floor ? 0 :
				  a>65535*t->scale+t->floor ? 65535 :
				  (int)((a-t->floor)/t->scale);
//				fprintf(stderr,"%d %d %d %f\n",
//				  j,k,t->terrain->y[j][k],a);
			}
		}
		mstsRoute->writeTerrain(t);
		t->freeTerrain();
	}
	free(elevData);
	GDALClose(rasterData);
}

The getElevation function uses linear interpolation to extract the elevation at the specified latitude and longitude from the GDAL provided data.

This code uses the MSTSRoute and Tile classes from my rail marine simulator. I assume TSRE has something similar.

The xy2ll function converts internal coordinates into latitude and longitude. My version uses Proj4 for this. This will need to be replaced with whatever TSRE uses.

The route I'm working on is small and it was covered by a single geotiff file. My code doesn't currently merge data from multiple files. I think the main thing that needs to be added is the ability to adjust the data already populated in a tile to use new scale and floor values.

Doug

[Genma Saotome]

eric from trainsim, on 11 September 2024 - 07:35 PM, said:

A new terrain engine would be idea, but that really should be part of an integrated editor that shares the same source code.

I'm happy to keep fixing little things here and there where it's easy enough to figure out with no real documentation, but won't be touching terrain on my own. There are only a few people who know how to make that work, and one of them is persona non grata to this and my community, and Goku is one of the others and wants nothing to do with further improvements.

If someone who understands how to build the data structure for terrain is willing to take a stab at the math to do something with higher resolution, I'll gladly do what I can to help fold that into TSRE.

A long time ago (in a galaxy far, far away) one of the OR people, Walt (RIP), investigated a completely different terrain form, one that was based entirely on triangles of whatever size made sense to produce the terrain. IIRC the conclusion was the resulting poly count was far too high for the size of visible terrain coupled to the contemporary computing power to be of practical use. PCs are much more powerful now, as are GPUs so maybe its time has come. At the time the private OR forum was used extensively and so if you search for "Walt" in those locations you'll probably find his reports on this matter. He also dealt with rail profiles.