[Genma Saotome]

Chris,

IMO the question of load vs. empty could be addressed by metadata but IMO it would be far better for the value of Mass() in any .eng or .wag to be that for the empty vehicle. What I think is needed is to add another couple of (real) data parameters -- MassLading (real) and LadingName ( String ). Having those as real parameter values instead of just metadata would say they are being used in the software -- such as in sprite text pointed to each car.

If MassLading() is insufficient for locomotives and/or tenders then add MassFuel() and MassWater().

I overlooked Railroad(). May I suggest instead Owner() as not all rolling stock is owned by a railroad (e.g., any tank car today).

Does WagAuthor( string) and EngAuthor( string ) work better than just Author()? Just Author() could be construed as the person who created everything whereas someone who does the .wag file may have nothing at all to do wither either mesh or texture.

Quote

- Change "BuilderModelName, OwnerModelName, OwnerModelCode" to "class" and add a "builder" field

I disagree. BuilderModelName ( string ) is the marketing name used by the builder. F7, SD9, PS-1, 10-6 Sleeper and so on. I think it would be extensively used in search. I thought of OwnerModelName ( string ) more as a nickname -- MacArthurs, Cadillac, and so on. Probably not going to be used very often. Maybe there is no need. I thought of OwnerModelCode ( string ) as the value the railroad uses in it's internal documentation. For example, a CN 4-8-2 steamer was class U1.

One open question is whether the metadata of things like F-7 should be just F-7 or F-7 Phase II. The later was never used officially but it does make sense.

That said, it would probably be an improvement to replace the word Model with Class giving BuilderClassName() and OwnerClassCode().

Quote

- condense the dates for acquired, retired, paint into one date range

Date ranges contain two datam not one (for the record I'm retired data architect). So you need to do something like this:

Topic (
	DateStart (  YYYY-MM )
	DateEnd ( YYYY-MM )
)

or

TopicDateStart (  YYYY-MM )
TopicDateEnd ( YYYY-MM )

or

TopicDateRange ( YYYY-MM, YYYY-MM )

.

My preference is highest for the first example, lowest for the third.

WRT consolidation into just one pair of dates, no, I think that's unwise. The person who creates the model probably knows a fair amount of information about it and so can provide a when the model was first put into use. He may also know when specific railroads retired the unit. This acts like bookends for everything else, but especially for reskinners. That's one "topic". The dates for paint scheme are, I think, very useful for everyone. That's a second "topic". The open question is whether a third topic for the years a railroad used a particular model is useful. Here again I was thinking of bookends for the reskinner.

[conductorchris]

Charles, it seems to me that your comment (with which I have sympathy) illustrates the tension between simplicity and completeness. There has to be a sweet spot where it is simple enough that it will be commonly used. On the other hand, the more information the original authors can provide (which might really go in the comments field?) the less chance for downstream users to insert their ignorance into things?
Christopher

[Genma Saotome]

conductorchris, on 02 August 2016 - 12:58 PM, said:

On the other hand, the more information the original authors can provide (which might really go in the comments field?) the less chance for downstream users to insert their ignorance into things?
Christopher

The problem w/ comment fields is the potentially important stuff is hard to find amid the mass of words. Looks at one of the MILW heavy electrics as an example.

[Jovet]

cr-stagg, on 02 August 2016 - 11:26 AM, said:

Some recent discussion about "new releases" by a vendor and repaints by some users has me shaking my head at what some are calling "MSTS & OR Compatible". I find that NO effort has been made with the ENG files to incorporate ORTS.

"Compatible" means just that: It works with both. No need to shake your head at that.

Adding OR-specific features would be great, yes, but then it could even be branded with "special Open Rails features" beyond merely compatible. One would think that would appeal to customers more.

[Genma Saotome]

I've continued to poke away at this topic. I think there are five categories of metadata:

Metadata (
	LicenceTerms (
	)
	Compatibility (
	)
	Identity (
	)
	Appearance (
	)
	Function (
	)
)

The first issue that comes to mind is whether any detailed information belong to any of the above are solely for a consist editor or instead serve some broader purpose? As an example, in LicenseTerms one might find "Payware" which arguable might be useful to a consist editor as a criteria to use for not including that unity in a consist you wanted to distribute in a file library but something else like who did the original modeling might only be useful if you wanted to contact that person.

Should both uses be allowed? I dunno. Opinions?

The second issue is, IMO much, much larger and that has to do with how one would use a consist editor to search on any of this metadata. I think the answer is rather complex and perhaps it doesn't make any sense to do very much with these ideas w/o getting some sort of buy-in from the fellow who offer consist editors. Let me explain...

If there are five basic categories the consist editor would have to do something akin to having a search window with five tabs, one tab for each of those categories. Within each tab there would have to be some mechanism to indicate which of any number of tags would be relevant to the search. As an example, possible tags for the Identity category might include this list:

	Identity (
		Owner ( string )		<-- e.g. Chicago & Northwestern
		Initials ( string )		<-- e.g., C&NW
		SerialNbr ( string )		<-- e.g., 124800, X104, etc.
		YearAcquired ( int )
		MonthAcquired ( int ) 		<--n.b., expected to be omitted in most cases
		YearDepreciated ( int )		<-- i.e., sold or retired from service
		MonthDepreciated ( int )	<-- n.b., expected to be omitted in most cases
		Builder			<-- e.g., EMD, AC&F, Sac Shops
		BuilderModelName ( string )	<--- e.g., SD-9, PS-1
		OwnerModelName ( string )	<--- e.g., Cadillac
		OwnerClassCode ( string )	<--- e.g., EF-5, B-50-24	
	)

So here is both a UI and functional question -- in technobable a use case: Does one enter the search value for some number of the above by typing in a value -- which may or may not be spelt correctly -- or should there be a pull down menu holding the known (distinct) values that exist within your roster of rolling stock? The later is much more complex a task to create... and a superior method for user interaction.

Another facet of this is the question of whether there is a "is" or "not" condition for strings? A greater than, greater than or equal to, less than, less than or equal to condition for numbers? Once again, much more complex for the programmer, vastly superior interaction for the end user.

Do that for five tabs. When does the user indicate he's done with the criteria? Beats me... so there must be a search now button and probably a reset button as well so you do not inadvertently retain criteria from the previous search in the present one.

Are searches cumulative or distinct? I don't know. The difference is, once again, significant for both programmer and end user.

I'm not sure of the answers to these issues... I would expect a survey of end users would likely show opinions all over the place and I'd expect any programmer to prefer less work than more. And so I'm not sure how to move this forward.

[Genma Saotome]

As for the detailed metadata... the lists I have written done are these:

For searching based on who has some relationship with the unit and when and how the unit itself is identified:

	Identity (
		Owner ( string )		<-- e.g. Chicago & Northwestern
		Initials ( string )		<-- e.g., C&NW
		SerialNbr ( string )		<-- e.g., 124800, X104, etc.
		YearAcquired ( int )
		MonthAcquired ( int ) 		<--n.b., expected to be omitted in most cases
		YearDepreciated ( int )		<-- i.e., sold or retired from service
		MonthDepreciated ( int )	<-- n.b., expected to be omitted in most cases
		Builder			<-- e.g., EMD, AC&F, Sac Shops
		BuilderModelName ( string )	<--- e.g., SD-9, PS-1
		OwnerModelName ( string )	<--- e.g., Cadillac
		OwnerClassCode ( string )	<--- e.g., EF-5, B-50-24	
	)

The idea here is to support high level searches on what, what, and when, such as everything from the ABC Railroad in use between data A and Date B.


For searches based on the appearance of the unit and when it looked that way:

	Appearance (
		MajorColors ( string )		<-- e.g., Black and Silver
		Nickname ( string )		<-- e.g., Black Widow
		YearFirstRelevant ( YYYY )	<-- i.e., first year of relevance for selection purposes of this unit
		MonthFirstRelevant ( MM )	<-- n.b., expected to be omitted in most cases
		YearLastRelevant ( YYYY )	<-- i.e., final year of relevance for selection purposes of this unit
		MonthLastRelevant ( MM )	<-- n.b., expected to be omitted in most cases
		Gauge ( real + UoM  )		<-- e.g., 56.5in, 42in, 1m, etc
		Length ( real + UoM  )		<-- e.g., 36ft,  40ft, etc
	)

That search supports finding equipment based on paint schemes and dates which would be very useful for locomotives but still applicable for certain other units types.


For searches on how the unit was used:

	Function (
		Type ( string )			<-- e.g., SteamLoco | DieselLoco | FreightCar |et al.
		NationalClassCode ( string )	<-- e.g., XM, GS, etc.
		CommonName ( string )	<-- e.g., Boxcar
	)

This metadata goes one step further than .eng vs. wag, Engine .vs. carriage .vs. wagon by describing what kind of engine, which kind of freight car and, as needed, a further subdivison by some sort of code you can search for freight cars for auto parts, etc.



And last (and most complex) for searching based on the license:

LicenceTerms (
		AsCreated (
			CreationDate ( YYYY-MM )
			Mesh (
				MeshLicenseType ( string )	<-- e.g., Limited Freeware, Limited Payware, Open Source
				MeshCreator ( string )		<-- e.g., George R.R. Martin, etc.
			)
			Art (
				ArtLicenseType ( string )	<-- e.g., Limited Freeware, Limited Payware, Open Source
				ArtCreator ( string		<-- e.g., Michael Angelo, etc.
			)
			DataFiles (
				EngWagCreator (string )	<-- e.g., Kevin Kilgrave, etc.
		)
		AsRevised (
			RevisonDate ( YYYY-MM )
			Added ( Mesh | Art | Both )
			Changed ( Mesh | Art | Both )
			Removed ( Mesh | Art | Both )
			RevisionDescribed ( string ) 
			RevisorName ( string )		<-- e.g., Ramsey Bolton, etc.
			RevisionLicenseType ( string )	<-- e.g., Limited Freeware, Limited Payware, Open Source
		)
		AsRevised  ( ** repeat as needed **
		)
	)

This last category could arguable be shrunk to just license types for both mesh and art so folks could filter for or against payware.

When you put it all together you should be able to do searches like these:

Search One
Identity.Initials =D&RGW
Identify.YearAcquired < 1950
Appearance.gauge = 56.5in
Appearance.length = 36ft
Function.CommonName = Boxcar


Search Two
Identity.Initials =SP
Identity.Builder = Baldwin
Appearance.MajorColors = Daylight

[Jovet]

My only question about date fields is what about regions that do not typically use the Gregorian calendar?

[Genma Saotome]

jovet, on 22 September 2016 - 04:13 PM, said:

My only question about date fields is what about regions that do not typically use the Gregorian calendar?

Find me a route and equipment that operates on such a calendar and lets assess its popularity.

[conductorchris]

How a consist editor search operates might be different from how the data is set up. One model is something like the yardmaster program that searches all kinds of information individually. The other is the approach of google and taken by goku's editor, with a single search box that searches multiple fields (perhaps it could have an advanced search too). Having used both, I like Goku's approach.

I think your metadata scheme shows some really clear thinking. Nice work.

Christopher

[Genma Saotome]

conductorchris, on 23 September 2016 - 06:12 AM, said:

Having used both, I like Goku's approach.

I think your metadata scheme shows some really clear thinking. Nice work.

Christopher

If you know excel filters then you are familiar with the issue of filtering by so many criteria -- both difficulty and opportunity.

I think the answer of what to do w/ a series of sear5ches is to hope there is a append to list choice. That way you could do multiple searches to create a custom (long) list. This leads me to think that perhaps the only way to do something like this is a dedicated search window with tabs.