[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.

[Goku]

Your data structure is too complicated. For example why so many Date elements?

YearFirstRelevant
MonthFirstRelevant

Better use DateFirstRelevant and allow formats YYYY, YYYY-MM, YYY-MM-DD etc.

Also, if one element has only two child elements, I prefer the second solution:

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

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

If more, first solution is better.

[Genma Saotome]

Why? Because I'm a data architect with a couple decades of experience.

Lemme explain (which I should have done earlier... sorry!): Documenting it as I've done makes it clear there are at least two different data there that people may want to search on. If within the program and file it makes sense to meet that requirement by combining the two data into one physical field, that may be ok with me so long as the requirement to be able to search on one or both elements is met but my default position will be to oppose it.

Generally speaking you don't want to couple one datum to another unless the search criteria is also always compounded. Date is probably the only safe one where you can do that. In contrast, doing something like PaintDate( "BlackWidow" 1946 1956) is the data equivalent of using a construct in code that nobody in the right mind would ever use. You just don't do it. The reasoning behind that statement is (1) doing so usually binds the data to a particular program, and (2) it doesn't eliminate any data -- you still have three -- and (3) it does obscure what they mean and usually gets in the way of efficient use.

Goku, I've seen data like this: Parameter AA ( d ) coupled with Parameter BB ( k 5 XX ) where the meaning of d depends on the value of XX. IOW, if XX was 1 d might have meant "Product Line F" but if XX was 14 d might have meant "Contact Customer before shipping". It was crazy and it was done because it was convenient for that programmer that week and caused headaches for years afterwards.

A datum is singular with a value dependent only upon owns logical definition. PaintDate(), above is not a datum. It's programmatic construct. You have to be real careful about forcing those on people via their data.

[Goku]

Your answer is not answer for my question. I agree that:
PaintDate( "BlackWidow" 1946 1956)
isn't good idea*, but splitting date into:
SomethingYear ()
SomethingMonth ()
SomethingDay ()
Is just very bad idea. No one does it that way. I definitely won't implement hundreds of different elements in my code.

*For games it is even good to use this format:
PaintDate( "BlackWidow" 1946 1956)
Because it is 3x faster loading time than separate element for every value.

[Genma Saotome]

I've said that's probably the one data that could reasonably be coupled (assuming the end user can select on some subset of the data values) and yet you come back with complaining about date formats again.

So what is the real problem here? The format of a date, searching .wags and .engs using metadata in general, or a desire to see your consist editor specifically search on metadata?

[Jovet]

Genma Saotome, on 22 September 2016 - 06:50 PM, said:

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

My suggestion wasn't born from what's already on the table. My suggestion was derived from forward thinking for the future. Dates are tricky things, and while the Gregorian calendar is widely used by almost everyone in industries like railroads, it isn't completely universal (e.g. Africa, maybe China, maybe Middle East). I think it would be prudent to consider support for limited other calendars.

I also think the suggestion for a singular date field is a good one. There are standardized ways to present dates (and times), some human-interpretable and some not. ISO 8601 is a worthwhile standard. While it is good to think forward about the interactions between the data and itself and its processor (the software) it is also possible to over-engineer things. An ISO 8601 date field can be easily parsed to get the needed data out of without adding extra overhead of additional groups.