I don't know about you and so called "security consultants", it's very, very easy to check offline (from a separate host) that a hard drive with a Windows partition on it has legitimate files as released by MS. Digital signatures and all that jazz. This whole reinstall attitude is frankly said getting on my nerves. Waste hours (if you're not in an imaged environment) on reinstalling a system where perhaps a couple files and a dozen or two registry entries are wrong?! Fuck no!
The way detached houses are built in the U.S., pretty much everyone who has a phone line coming in, has it exposed outside. Even though there's no physical phone installed, it'd take someone maybe 15 seconds to hook one up. Including a battery backed wireless phone base.
Now, even though network demarc points are usually inside, there's often customer premise wiring routed outside the house, especially if fax or DSL lines were added after the house was built. This means that, more often than not, even if you're using a cable modem or an VoIP-to-analog adapter, there will be a dialtone accessible from the outside even if it's not the telco providing it anymore.
While I agree in principle, you're very wrong on details. Most (as in 4 nines at least) of distribution of pornographic material of any kind (legal and not) is done without cash or any other compensation changing hands. The production of the stuff most people download has been paid off long ago. Jailing porn collectors who don't pay for their stuff is pretty much pointless -- it doesn't do anything to prevent anyone from being raped.
48 in 2009? I wouldn't complain. It's in the same ballpark as mining deaths in the same year (34). I think that in most police manuals there's a section about use of force, and sending a SWAT-like group after a guy who is not known to be dangerous is preposterous.
Automating image recognition is on the same level of complication as deploying a metrological-grade radar/lidar sensor: not trivial, but not impossible.
The automated modules you allude to are, to say the least, not very robust when it comes to integrity of their output. The NHTSA standards -- DOT HS 808 069 and DOT HS 810 845 -- read like something from 1950s, when it comes to technical requirements and technology used. It's literally no different than your basic doppler radar from the end of 2nd world war. The truth is that police radar and lidar guns are simple doppler + time-of-flight devices that are sensitive to interference (vibrating roadside signs, vibrating panels on the vehicles, rotating parts on the vehicles) and I'm absolutely unconvinced that they should be allowed to be used at all.
Non-imaging Doppler radar/lidar is dumb: it doesn't care if it measures the speed of the vehicle, or just a small part of it, or even something else that was nearby. You can't really tell it either. Once you go into imaging sensors, it becomes much cheaper to use optical imaging. Even if you wanted to do a full-field Doppler imaging optically, it'd be cheaper than doing it with microwaves.
I do engineering for a living and those are all valid concerns. That's why you have engineers solving them;) Of course it's not trivial, but -- again -- harder things in automated image analysis have been done successfully. Your concerns about lane shifting are solveable only when you do image analysis, they become impossible obstacles when you have "dumb" radar or lidar systems. By dumb I mean systems that don't do imaging, the latter being rather expensive.
If you want a more robust system, add a second camera and an IR pattern projector like in a Kinect. Suddenly vehicle detection becomes much easier -- road doesn't jump around. Once you transform the coordinate system to align everything with the road surface, you detect vehicles by doing a binary threshold on height. Then you trivially detect continuous blobs. And that's pretty much it. The only concern is precipitation -- when too many spots in the illumination get blocked, the algorithm that Kinect uses can't but give up.
Oh boy. The camera is fixed. The lanes are fixed. Object detection without classification is fairly easy. So you detect a car at one point on the lane, you derive its mask, save the masked image. On the next frame, you match all other cars in the same lane to the one you detected. Stuff in-between lanes, not matching the saved reference, etc. gets discarded. Rinse and repeat. If your framerate and field of view are right, you should be able to use more than 2 frames, and only if detection and matching give mutually reassuring results in all frames, then you take the centroid as valid and calculate speed.
I don't think you'd even need to do automatic plate recognition here, presumably a human's time is cheap enough since you're getting paid for the ticket anyway. Mechanical turk to the rescue and all that.
Plate recognition is a must for things like automated toolbooths that have -- guess what -- dropped technologically much simpler transponders for image recognition! At least in Colorado I don't need anything special in a rental car to use toll roads. The car doesn't have a transponder, I just drive through, plate pictures are taken, and everything is handled digitally from that point onwards, all the way to billing the credit card I used to rent the car a week or two later.
The object selection issue you are talking about is in a class of problems that have been pretty much solved many times over.
Reliability wise, here software beats additional hardware hands down. You have less hardware as the only thing you need is a camera. If you're adventurous, you could use a DSLR that can snap a couple pics a second, and process that to get improved resolution and remove need for potentially many cameras on multi-lane installs.
The whole system can be, more-or-less, an environmental enclosure with an external antenna for some sort of remote connectivity, a window for the DSLR, the DSLR itself, and a fast enough industrial PC.
Radar is accurate only once you apply fairly complex processing to the signal. You know, not cutting corners in engineering the thing, and giving it all the attention that law enforcement metrology would demand. The way both radar and lidar are currently implemented: you better not have a vibrating antenna anywhere on your car. A lidar pointed to a leisurely spinning (wind-driven) fan of a turbofan engine in a parked plane will happily report the back-and-forth apparent motion of the spinning fan blades. Same happens when there's anything vibrating back-and-forth on your car, with a component that's in line with radar's or lidar's beam direction. It's fairly easy to get current lidar systems to report speeds in excess of 20mph just by waving them slightly against a ragged wall. From a viewpoint of metrology, the only thing a lidar gun is good for is measuring speed of tennis balls in a long paper tube painted black. For anything else it's a random number generator with a slight bias.
The "photo comparison stuff" is pretty much part of an off-the-shelf image analysis library. Since you have the cameras, may as well use them to fullest extent. No need to add extra hardware to the system.
Those speed cameras don't have to use any radar/lidar at all. Just take pictures of cars as they pass at regular intervals, use image recognition to locate some centroid of each car in two frames, and issue a ticket if the distance exceeds a preset limit. You have a clear doumentation of the transgression right there. Heck, the time can be displayed on a separate digital display visible in the camera's field of view. Ideally supplied by another vendor. That'd be quite incontrovertible.
And it's different from Flash how? All I know is that technically Silverlight runs on a much more capable platform. I also trust.net runtime much more than any Flash VM. And I'm no microsoft fanboy.
I think you're making it more of a problem than it really is. At least when it comes to dealing with length measurements on a scale used by tradesmen, it's no problem.
As much as I like SI units, for some purposes imperial measurements are just more convenient. For example A.W.G. wire sizes. You just know that if you have #10 wire, the next common larger size is #8, and the next smaller common size is #12. The equivalent metric wire cross-sections are 6, 10 and 4, respectively. As you progress towards smaller wire, you simply have #14, #16, #18, etc., but with mm^2 you get 2.5, 1.5, 1.0. The A.W.G. is a simpler system to navigate -- use increments of 2, larger number is smaller diameter, and that's about it. With cross-sectional areas used in metric wire sizing, you have to memorize a table of valid values -- in the U.S. one uses indexes into such a table. At least with indexes you know how to get a valid one easily.
I find the thread measurements to be quite unproblematic. You almost always specify diameter and pitch, for example a coarse thread of #10 (approx M4.8) diameter is 10-24 (24 turns per inch), while a fine thread is 10-32. In the metric system, you have to specify major diameter and pitch too, so that's no different, except for the choice of units.
About the only semi-useful thing with the M thread sizes is that the number after M indicates the major thread diameter. That's different from the thread "number" (say #10 ~ M4.8): the latter has no linear relationship to inches. Alas, the major thread diameter is useless for anything besides identification of the thread! If you need to know the sizes of clearance or tap drills, you have to use tables whether it's the U.S. or metric thread.
The only "byzantine" aspect of the thread number to diameter table that you mention is the arbitrary choice of thread sizes. There's nothing else to it. When dealing with small fasteners (think fine mechanics/optics), metric threads are just as arbitrary: M1.0, M1.1 and M1.2 are common sizes, but you wouldn't know offhand that M1.3 is not common, and the next size is M1.4, and the next is M1.6. With U.S. thread sizes it fairly similar: any natural number between #0 and #6 is common, then it switches to increments of 2 up to #12, then you go with inch sizes starting at 1/4" in 1/16" increments up to 5/8", then it switches to increments of 1/8", then above 1 1/2" it switches to quarter inch increments, etc.
As for fractional inches that tradesmen use: it's simply binary fractions. There's no fundamental difference from decimal fractions, apart from the choice of base! A typical tape measure has two scales, one with smallest division of 0.001_2" (_2 means base 2), another with smallest division of 0.000'1_2". When you see a 3/64" drill size, you need to see it as 0.000'011_2", and the next larger size is 0.000'100_2" (1/16"). It's hardly any different from decimal fractions apart from the choice of a low base increasing the number of digits you have to keep around. If you like less digits, simply learn to do mental math in octal base. 1/8" drill is then 0.1_8", 3/64" is 0.03_8" thus one more gives you 0.04_8" - that's one sixteenth.
I have been doing plenty of home renovations, and I simply learned use the octal representation. After a few months I instinctively represent binary fractions as octal fractions. It works with feet, too: a foot is 14_8 inches, so while it's a unit in base 12 (1_12 = 14_8), it's not that hard to deal with -- conceptually it no different from counting by fives, three at a time. You'll have no problem counting 0, 15, 30, 45, 60, 75 because you're familiar with analog clocks -- it's same as with counting feet in octal inches: 0, 14, 30, 44, 60, 74,...
That's OK, because you're still treating the unit as a number in decimal representation. It's easy to go from mils to inches, just like it's easy to go from mm to metres. In electronics you don't measure things in feet or binary fractions of an inch (1/2, 1/4, 1/8, etc).
Good luck! I can't beat paragliding, but me and the wife are trying to "adopt" an undergrad couple for at least a weekend, and perhaps for the summer if that'd go well. What better way to feel young than to surround yourself with people younger than you are;), never mind that they genuinely made us curious and wanting to get to know them better. We'll see. We're not that much older, just a decade.
NetBeans is an IDE. It mostly doesn't give crap about what the compilers do, apart from producing an "understandable" debug information file with the executable, and the debugger being able to control the executable and extract/modify memory and registers. Even if, somehow, NetBeans didn't come with necessary debugger functionality needed to debug 64 bit executables, or if it didn't have the project setup dialogs expose the 64 bit target option, it should be an easy fix (perhaps less than 1000 lines worth of changed/added code).
When I last tried (a couple years ago) it was fairly easy to coax NetBeans to use a Zilog C compiler for the ez8 target. I only had to add a JNI blurb to expose Zilog's debugger dll, and some glue between that and rest of the IDE.
I think you missed the key issue: Netbeans is a java application. As long as you have a 64 bit java runtime installed, netbeans should happily run in that. There may be a native 32 bit executable that starts things up, but it'd be separate from the java runtime and won't prevent a 64 bit runtime from running. That's what I make of it, at least.
If the copier device is competently designed, it'll have ESD protection on the inputs and it won't as much as wink when wired to the LCD backlight inverter's output. For all I know, it will withstand a cellphone's backlight inverter's output on the USB data or power pins indefinitely.
IANAL, but the following comes straight from the horse's mouth. I will use Denver as an example locality.
Infractions are civil matters. You cannot get arrested for them (DPOM 204.06.3.c, "Arrests for traffic infractions are not allowed."), and you won't go to jail for them -- not unless you do something else, like failing to show up for a court date, that is. Local laws (state / municipal) usually default to treating everything as a criminal offence (DRMC 1-13) and enumerating what isn't (DRMC 54-4). You can be arrested when you commit a crime -- that is a criminal act, and infractions aren't (CRS 16-3-102 "A peace officer may arrest a person when: [...](b) Any crime has been or is being committed by such person in his presence") (DPOM 204.05.2.a "No individual will be jailed on misdemeanor traffic charges, including D.U.I., unless one of the following criteria is met [...]").
CRS is very clear in defining the scope of rules in title 16, I'm not making it up: "This code is intended to provide for the just determination of every criminal proceeding." (CRS 16-1-103). An infraction is not a crime, thus 16-3-102 does not apply, and the police operations manual (DPOM) clearly restates that.
At least in the U.S., facts (or "information") are not subject to copyright. IOW: as far as U.S. law is concerned, your entire argument is full of shit. So if he went and measured all those wheelbases etc. himself, would it make any more useful? No, and the U.S. law recognizes that busywork does not add any value. If specs for a car are known, there's no point in having it excessively protected from dissemination. His work was in collecting all the information from different sources, categorizing it (a librarian's type of work), and making it available in a concise, searchable form. I applaud such efforts. To think otherwise must imply that you'd much rather not have library catalogs either. It's just a "collation" of "mountains" of "information", and thus useless, and surely libraries are not owning any copyrights over that hahaha. Shut up.
Slashdot Mirror
Do they have, um, study rooms? /me ducks and runs
I don't know about you and so called "security consultants", it's very, very easy to check offline (from a separate host) that a hard drive with a Windows partition on it has legitimate files as released by MS. Digital signatures and all that jazz. This whole reinstall attitude is frankly said getting on my nerves. Waste hours (if you're not in an imaged environment) on reinstalling a system where perhaps a couple files and a dozen or two registry entries are wrong?! Fuck no!
Perhaps the most informative post of this whole thread. Thank you!
Marry an E.U. citizen. There are some pretty girls in Europe ;)
The way detached houses are built in the U.S., pretty much everyone who has a phone line coming in, has it exposed outside. Even though there's no physical phone installed, it'd take someone maybe 15 seconds to hook one up. Including a battery backed wireless phone base.
Now, even though network demarc points are usually inside, there's often customer premise wiring routed outside the house, especially if fax or DSL lines were added after the house was built. This means that, more often than not, even if you're using a cable modem or an VoIP-to-analog adapter, there will be a dialtone accessible from the outside even if it's not the telco providing it anymore.
While I agree in principle, you're very wrong on details. Most (as in 4 nines at least) of distribution of pornographic material of any kind (legal and not) is done without cash or any other compensation changing hands. The production of the stuff most people download has been paid off long ago. Jailing porn collectors who don't pay for their stuff is pretty much pointless -- it doesn't do anything to prevent anyone from being raped.
48 in 2009? I wouldn't complain. It's in the same ballpark as mining deaths in the same year (34). I think that in most police manuals there's a section about use of force, and sending a SWAT-like group after a guy who is not known to be dangerous is preposterous.
Automating image recognition is on the same level of complication as deploying a metrological-grade radar/lidar sensor: not trivial, but not impossible.
The automated modules you allude to are, to say the least, not very robust when it comes to integrity of their output. The NHTSA standards -- DOT HS 808 069 and DOT HS 810 845 -- read like something from 1950s, when it comes to technical requirements and technology used. It's literally no different than your basic doppler radar from the end of 2nd world war. The truth is that police radar and lidar guns are simple doppler + time-of-flight devices that are sensitive to interference (vibrating roadside signs, vibrating panels on the vehicles, rotating parts on the vehicles) and I'm absolutely unconvinced that they should be allowed to be used at all.
Non-imaging Doppler radar/lidar is dumb: it doesn't care if it measures the speed of the vehicle, or just a small part of it, or even something else that was nearby. You can't really tell it either. Once you go into imaging sensors, it becomes much cheaper to use optical imaging. Even if you wanted to do a full-field Doppler imaging optically, it'd be cheaper than doing it with microwaves.
I do engineering for a living and those are all valid concerns. That's why you have engineers solving them ;) Of course it's not trivial, but -- again -- harder things in automated image analysis have been done successfully. Your concerns about lane shifting are solveable only when you do image analysis, they become impossible obstacles when you have "dumb" radar or lidar systems. By dumb I mean systems that don't do imaging, the latter being rather expensive.
If you want a more robust system, add a second camera and an IR pattern projector like in a Kinect. Suddenly vehicle detection becomes much easier -- road doesn't jump around. Once you transform the coordinate system to align everything with the road surface, you detect vehicles by doing a binary threshold on height. Then you trivially detect continuous blobs. And that's pretty much it. The only concern is precipitation -- when too many spots in the illumination get blocked, the algorithm that Kinect uses can't but give up.
Oh boy. The camera is fixed. The lanes are fixed. Object detection without classification is fairly easy. So you detect a car at one point on the lane, you derive its mask, save the masked image. On the next frame, you match all other cars in the same lane to the one you detected. Stuff in-between lanes, not matching the saved reference, etc. gets discarded. Rinse and repeat. If your framerate and field of view are right, you should be able to use more than 2 frames, and only if detection and matching give mutually reassuring results in all frames, then you take the centroid as valid and calculate speed.
I don't think you'd even need to do automatic plate recognition here, presumably a human's time is cheap enough since you're getting paid for the ticket anyway. Mechanical turk to the rescue and all that.
Plate recognition is a must for things like automated toolbooths that have -- guess what -- dropped technologically much simpler transponders for image recognition! At least in Colorado I don't need anything special in a rental car to use toll roads. The car doesn't have a transponder, I just drive through, plate pictures are taken, and everything is handled digitally from that point onwards, all the way to billing the credit card I used to rent the car a week or two later.
The object selection issue you are talking about is in a class of problems that have been pretty much solved many times over.
Reliability wise, here software beats additional hardware hands down. You have less hardware as the only thing you need is a camera. If you're adventurous, you could use a DSLR that can snap a couple pics a second, and process that to get improved resolution and remove need for potentially many cameras on multi-lane installs.
The whole system can be, more-or-less, an environmental enclosure with an external antenna for some sort of remote connectivity, a window for the DSLR, the DSLR itself, and a fast enough industrial PC.
Radar is accurate only once you apply fairly complex processing to the signal. You know, not cutting corners in engineering the thing, and giving it all the attention that law enforcement metrology would demand. The way both radar and lidar are currently implemented: you better not have a vibrating antenna anywhere on your car. A lidar pointed to a leisurely spinning (wind-driven) fan of a turbofan engine in a parked plane will happily report the back-and-forth apparent motion of the spinning fan blades. Same happens when there's anything vibrating back-and-forth on your car, with a component that's in line with radar's or lidar's beam direction. It's fairly easy to get current lidar systems to report speeds in excess of 20mph just by waving them slightly against a ragged wall. From a viewpoint of metrology, the only thing a lidar gun is good for is measuring speed of tennis balls in a long paper tube painted black. For anything else it's a random number generator with a slight bias.
The "photo comparison stuff" is pretty much part of an off-the-shelf image analysis library. Since you have the cameras, may as well use them to fullest extent. No need to add extra hardware to the system.
Those speed cameras don't have to use any radar/lidar at all. Just take pictures of cars as they pass at regular intervals, use image recognition to locate some centroid of each car in two frames, and issue a ticket if the distance exceeds a preset limit. You have a clear doumentation of the transgression right there. Heck, the time can be displayed on a separate digital display visible in the camera's field of view. Ideally supplied by another vendor. That'd be quite incontrovertible.
This should be informative -- those robots are impressive to see.
And it's different from Flash how? All I know is that technically Silverlight runs on a much more capable platform. I also trust .net runtime much more than any Flash VM. And I'm no microsoft fanboy.
I think you're making it more of a problem than it really is. At least when it comes to dealing with length measurements on a scale used by tradesmen, it's no problem.
As much as I like SI units, for some purposes imperial measurements are just more convenient. For example A.W.G. wire sizes. You just know that if you have #10 wire, the next common larger size is #8, and the next smaller common size is #12. The equivalent metric wire cross-sections are 6, 10 and 4, respectively. As you progress towards smaller wire, you simply have #14, #16, #18, etc., but with mm^2 you get 2.5, 1.5, 1.0. The A.W.G. is a simpler system to navigate -- use increments of 2, larger number is smaller diameter, and that's about it. With cross-sectional areas used in metric wire sizing, you have to memorize a table of valid values -- in the U.S. one uses indexes into such a table. At least with indexes you know how to get a valid one easily.
I find the thread measurements to be quite unproblematic. You almost always specify diameter and pitch, for example a coarse thread of #10 (approx M4.8) diameter is 10-24 (24 turns per inch), while a fine thread is 10-32. In the metric system, you have to specify major diameter and pitch too, so that's no different, except for the choice of units.
About the only semi-useful thing with the M thread sizes is that the number after M indicates the major thread diameter. That's different from the thread "number" (say #10 ~ M4.8): the latter has no linear relationship to inches. Alas, the major thread diameter is useless for anything besides identification of the thread! If you need to know the sizes of clearance or tap drills, you have to use tables whether it's the U.S. or metric thread.
The only "byzantine" aspect of the thread number to diameter table that you mention is the arbitrary choice of thread sizes. There's nothing else to it. When dealing with small fasteners (think fine mechanics/optics), metric threads are just as arbitrary: M1.0, M1.1 and M1.2 are common sizes, but you wouldn't know offhand that M1.3 is not common, and the next size is M1.4, and the next is M1.6. With U.S. thread sizes it fairly similar: any natural number between #0 and #6 is common, then it switches to increments of 2 up to #12, then you go with inch sizes starting at 1/4" in 1/16" increments up to 5/8", then it switches to increments of 1/8", then above 1 1/2" it switches to quarter inch increments, etc.
As for fractional inches that tradesmen use: it's simply binary fractions. There's no fundamental difference from decimal fractions, apart from the choice of base! A typical tape measure has two scales, one with smallest division of 0.001_2" (_2 means base 2), another with smallest division of 0.000'1_2". When you see a 3/64" drill size, you need to see it as 0.000'011_2", and the next larger size is 0.000'100_2" (1/16"). It's hardly any different from decimal fractions apart from the choice of a low base increasing the number of digits you have to keep around. If you like less digits, simply learn to do mental math in octal base. 1/8" drill is then 0.1_8", 3/64" is 0.03_8" thus one more gives you 0.04_8" - that's one sixteenth.
I have been doing plenty of home renovations, and I simply learned use the octal representation. After a few months I instinctively represent binary fractions as octal fractions. It works with feet, too: a foot is 14_8 inches, so while it's a unit in base 12 (1_12 = 14_8), it's not that hard to deal with -- conceptually it no different from counting by fives, three at a time. You'll have no problem counting 0, 15, 30, 45, 60, 75 because you're familiar with analog clocks -- it's same as with counting feet in octal inches: 0, 14, 30, 44, 60, 74, ...
That's OK, because you're still treating the unit as a number in decimal representation. It's easy to go from mils to inches, just like it's easy to go from mm to metres. In electronics you don't measure things in feet or binary fractions of an inch (1/2, 1/4, 1/8, etc).
Good luck! I can't beat paragliding, but me and the wife are trying to "adopt" an undergrad couple for at least a weekend, and perhaps for the summer if that'd go well. What better way to feel young than to surround yourself with people younger than you are ;), never mind that they genuinely made us curious and wanting to get to know them better. We'll see. We're not that much older, just a decade.
NetBeans is an IDE. It mostly doesn't give crap about what the compilers do, apart from producing an "understandable" debug information file with the executable, and the debugger being able to control the executable and extract/modify memory and registers. Even if, somehow, NetBeans didn't come with necessary debugger functionality needed to debug 64 bit executables, or if it didn't have the project setup dialogs expose the 64 bit target option, it should be an easy fix (perhaps less than 1000 lines worth of changed/added code).
When I last tried (a couple years ago) it was fairly easy to coax NetBeans to use a Zilog C compiler for the ez8 target. I only had to add a JNI blurb to expose Zilog's debugger dll, and some glue between that and rest of the IDE.
I think you missed the key issue: Netbeans is a java application. As long as you have a 64 bit java runtime installed, netbeans should happily run in that. There may be a native 32 bit executable that starts things up, but it'd be separate from the java runtime and won't prevent a 64 bit runtime from running. That's what I make of it, at least.
The reading would be done directly on the SEM image, you don't need to put it in a CD reader or "press" anything. Duh.
If the copier device is competently designed, it'll have ESD protection on the inputs and it won't as much as wink when wired to the LCD backlight inverter's output. For all I know, it will withstand a cellphone's backlight inverter's output on the USB data or power pins indefinitely.
IANAL, but the following comes straight from the horse's mouth. I will use Denver as an example locality.
Infractions are civil matters. You cannot get arrested for them (DPOM 204.06.3.c, "Arrests for traffic infractions are not allowed."), and you won't go to jail for them -- not unless you do something else, like failing to show up for a court date, that is. Local laws (state / municipal) usually default to treating everything as a criminal offence (DRMC 1-13) and enumerating what isn't (DRMC 54-4). You can be arrested when you commit a crime -- that is a criminal act, and infractions aren't (CRS 16-3-102 "A peace officer may arrest a person when: [...](b) Any crime has been or is being committed by such person in his presence") (DPOM 204.05.2.a "No individual will be jailed on misdemeanor traffic charges, including D.U.I., unless one of the following criteria is met [...]").
CRS is very clear in defining the scope of rules in title 16, I'm not making it up: "This code is intended to provide for the just determination of every criminal proceeding." (CRS 16-1-103). An infraction is not a crime, thus 16-3-102 does not apply, and the police operations manual (DPOM) clearly restates that.
Of course other jurisdictions may vary.
At least in the U.S., facts (or "information") are not subject to copyright. IOW: as far as U.S. law is concerned, your entire argument is full of shit. So if he went and measured all those wheelbases etc. himself, would it make any more useful? No, and the U.S. law recognizes that busywork does not add any value. If specs for a car are known, there's no point in having it excessively protected from dissemination. His work was in collecting all the information from different sources, categorizing it (a librarian's type of work), and making it available in a concise, searchable form. I applaud such efforts. To think otherwise must imply that you'd much rather not have library catalogs either. It's just a "collation" of "mountains" of "information", and thus useless, and surely libraries are not owning any copyrights over that hahaha. Shut up.