| Internet Engineering Task Force | A. Wright, Ed. |
| Internet-Draft | |
| Intended status: Informational | H. Andrews, Ed. |
| Expires: September 20, 2018 | Cloudflare, Inc. |
| G. Luff | |
| March 19, 2018 |
JSON Schema Validation: A Vocabulary for Structural Validation of JSON
draft-handrews-json-schema-validation-01
JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like.
The issues list for this draft can be found at <https://github.com/json-schema-org/json-schema-spec/issues>.
For additional information, see <http://json-schema.org/>.
To provide feedback, use this issue tracker, the communication methods listed on the homepage, or email the document editors.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 20, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
JSON Schema can be used to require that a given JSON document (an instance) satisfies a certain number of criteria. These criteria are asserted by using keywords described in this specification. In addition, a set of keywords is also defined to assist in interactive user interface instance generation.
This specification will use the concepts, syntax, and terminology defined by the JSON Schema core [json-schema] specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This specification uses the term "container instance" to refer to both array and object instances. It uses the term "children instances" to refer to array elements or object member values.
Elements in an array value are said to be unique if no two elements of this array are equal [json-schema].
JSON Schema validation applies schemas to locations within the instance, and asserts constraints on the structure of the data at each location. An instance location that satisfies all asserted constraints is then annotated with any keywords that contain non-assertion information, such as descriptive metadata and usage hints. If all locations within the instance satisfy all asserted constraints, then the instance is said to be valid against the schema.
Each schema object is independently evaluated against each instance location to which it applies. This greatly simplifies the implementation requirements for validators by ensuring that they do not need to maintain state across the document-wide validation process.
Validation begins by applying the root schema to the complete instance document. From there, various keywords are used to determine which additional subschemas are applied to either the current location, or a child location. These keywords also define whether and how subschema assertion results are modified and/or combined. Such keywords do not assert conditions on their own. Rather, they control how assertions are applied and evaluated.
The keywords in the boolean logic [logic] and conditional [conditional] sections of this specification apply subschemas to the same location as the parent schema. The former group defines boolean operations on the subschema assertion results, while the latter evaluates one subschema and uses its assertion results to determine which of two other subschemas to apply as well.
Several keywords determine which subschemas are applied to array items, object property values, and object property names. They are: "items", "additionalItems", "contains", "properties", "patternProperties", "additionalProperties", and "propertyNames". The "contains" keyword only requires its subschema to be valid against at least one child instance, while the other keywords require that all subschemas are valid against all child instances to which they apply.
Validation keywords typically operate independently, without affecting each other's outcomes.
For schema author convenience, there are some exceptions among the keywords that control subschema applicability:
Validation is a process of checking assertions. Each assertion adds constraints that an instance must satisfy in order to successfully validate.
Assertion keywords that are absent never restrict validation. In some cases, this no-op behavior is identical to a keyword that exists with certain values, and these values are noted where known.
All of the keywords in the general [general], numeric [numeric], and string [string] sections are assertions, as well as "minItems", "maxItems", "uniqueItems", "minProperties", "maxProperties", and "required". Additionally, "dependencies" is shorthand for a combination of conditional and assertion keywords.
The "format", "contentType", and "contentEncoding" keywords can also be implemented as assertions, although that functionality is an optional part of this specification, and the keywords convey additional non-assertion information.
Most validation assertions only constrain values within a certain primitive type. When the type of the instance is not of the type targeted by the keyword, the instance is considered to conform to the assertion.
For example, the "maxLength" keyword will only restrict certain strings (that are too long) from being valid. If the instance is a number, boolean, null, array, or object, then it is valid against this assertion.
In addition to assertions, this specification provides a small vocabulary of metadata keywords that can be used to annotate the JSON instance with useful information. The Section 7 and Section 8 keywords are also useful as annotations as well as being optional assertions, as they convey additional usage guidance for the instance data.
A schema that is applicable to a particular location in the instance, against which the instance location is valid, attaches its annotations to that location in the instance. Since many subschemas can be applicable to any single location, annotation keywords need to specify any unusual handling of multiple applicable occurrences of the keyword with different values. The default behavior is simply to collect all values.
Additional vocabularies SHOULD make use of this mechanism for applying their own annotations to instances.
Annotations are collected whenever an instance is valid against a schema object, and all of that schema object's parent schemas.
In particular, annotations in a subschema contained within a "not", at any depth, including any number of intervening additional "not" subschemas, MUST be ignored. If the instance was valid against the "not" subschema, then by definition it is not valid against the schema that contains the "not", so the "not" subschema's annotations are not used.
Similarly, annotations within a failing branch of a "oneOf", "anyOf", "then", or "else" MUST be ignored even when the instance successfully validates against the complete schema document.
Annotation keywords MUST be applied to all possible sub-instances. Even if such application can be short-circuited when only assertion evaluation is needed. For instance, the "contains" keyword need only be checked for assertions until at least one array item proves valid. However, when working with annotations, all items in the array must be evaluated to determine all items with which the annotations should be associated.
It should be noted that the nul character (\u0000) is valid in a JSON string. An instance to validate may contain a string value with this character, regardless of the ability of the underlying programming language to deal with such data.
The JSON specification allows numbers with arbitrary precision, and JSON Schema does not add any such bounds. This means that numeric instances processed by JSON Schema can be arbitrarily large and/or have an arbitrarily long decimal part, regardless of the ability of the underlying programming language to deal with such data.
Two validation keywords, "pattern" and "patternProperties", use regular expressions to express constraints, and the "regex" value for the "format" keyword constrains the instance value to be a regular expression.
Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:
Finally, implementations MUST NOT take regular expressions to be anchored, neither at the beginning nor at the end. This means, for instance, the pattern "es" matches "expression".
The current URI for the JSON Schema Validation is <http://json-schema.org/draft-07/schema#>.
Validation keywords in a schema impose requirements for successful validation of an instance.
The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique.
String values MUST be one of the six primitive types ("null", "boolean", "object", "array", "number", or "string"), or "integer" which matches any number with a zero fractional part.
An instance validates if and only if the instance is in any of the sets listed for this keyword.
The value of this keyword MUST be an array. This array SHOULD have at least one element. Elements in the array SHOULD be unique.
An instance validates successfully against this keyword if its value is equal to one of the elements in this keyword's array value.
Elements in the array might be of any value, including null.
The value of this keyword MAY be of any type, including null.
An instance validates successfully against this keyword if its value is equal to the value of the keyword.
The value of "multipleOf" MUST be a number, strictly greater than 0.
A numeric instance is valid only if division by this keyword's value results in an integer.
The value of "maximum" MUST be a number, representing an inclusive upper limit for a numeric instance.
If the instance is a number, then this keyword validates only if the instance is less than or exactly equal to "maximum".
The value of "exclusiveMaximum" MUST be number, representing an exclusive upper limit for a numeric instance.
If the instance is a number, then the instance is valid only if it has a value strictly less than (not equal to) "exclusiveMaximum".
The value of "minimum" MUST be a number, representing an inclusive lower limit for a numeric instance.
If the instance is a number, then this keyword validates only if the instance is greater than or exactly equal to "minimum".
The value of "exclusiveMinimum" MUST be number, representing an exclusive lower limit for a numeric instance.
If the instance is a number, then the instance is valid only if it has a value strictly greater than (not equal to) "exclusiveMinimum".
The value of this keyword MUST be a non-negative integer.
A string instance is valid against this keyword if its length is less than, or equal to, the value of this keyword.
The length of a string instance is defined as the number of its characters as defined by RFC 7159 [RFC7159].
The value of this keyword MUST be a non-negative integer.
A string instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword.
The length of a string instance is defined as the number of its characters as defined by RFC 7159 [RFC7159].
Omitting this keyword has the same behavior as a value of 0.
The value of this keyword MUST be a string. This string SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect.
A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored.
The value of "items" MUST be either a valid JSON Schema or an array of valid JSON Schemas.
This keyword determines how child instances validate for arrays, and does not directly validate the immediate instance itself.
If "items" is a schema, validation succeeds if all elements in the array successfully validate against that schema.
If "items" is an array of schemas, validation succeeds if each element of the instance validates against the schema at the same position, if any.
Omitting this keyword has the same behavior as an empty schema.
The value of "additionalItems" MUST be a valid JSON Schema.
This keyword determines how child instances validate for arrays, and does not directly validate the immediate instance itself.
If "items" is an array of schemas, validation succeeds if every instance element at a position greater than the size of "items" validates against "additionalItems".
Otherwise, "additionalItems" MUST be ignored, as the "items" schema (possibly the default value of an empty schema) is applied to all elements.
Omitting this keyword has the same behavior as an empty schema.
The value of this keyword MUST be a non-negative integer.
An array instance is valid against "maxItems" if its size is less than, or equal to, the value of this keyword.
The value of this keyword MUST be a non-negative integer.
An array instance is valid against "minItems" if its size is greater than, or equal to, the value of this keyword.
Omitting this keyword has the same behavior as a value of 0.
The value of this keyword MUST be a boolean.
If this keyword has boolean value false, the instance validates successfully. If it has boolean value true, the instance validates successfully if all of its elements are unique.
Omitting this keyword has the same behavior as a value of false.
The value of this keyword MUST be a valid JSON Schema.
An array instance is valid against "contains" if at least one of its elements is valid against the given schema.
The value of this keyword MUST be a non-negative integer.
An object instance is valid against "maxProperties" if its number of properties is less than, or equal to, the value of this keyword.
The value of this keyword MUST be a non-negative integer.
An object instance is valid against "minProperties" if its number of properties is greater than, or equal to, the value of this keyword.
Omitting this keyword has the same behavior as a value of 0.
The value of this keyword MUST be an array. Elements of this array, if any, MUST be strings, and MUST be unique.
An object instance is valid against this keyword if every item in the array is the name of a property in the instance.
Omitting this keyword has the same behavior as an empty array.
The value of "properties" MUST be an object. Each value of this object MUST be a valid JSON Schema.
This keyword determines how child instances validate for objects, and does not directly validate the immediate instance itself.
Validation succeeds if, for each name that appears in both the instance and as a name within this keyword's value, the child instance for that name successfully validates against the corresponding schema.
Omitting this keyword has the same behavior as an empty object.
The value of "patternProperties" MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect. Each property value of this object MUST be a valid JSON Schema.
This keyword determines how child instances validate for objects, and does not directly validate the immediate instance itself. Validation of the primitive instance type against this keyword always succeeds.
Validation succeeds if, for each instance name that matches any regular expressions that appear as a property name in this keyword's value, the child instance for that name successfully validates against each schema that corresponds to a matching regular expression.
Omitting this keyword has the same behavior as an empty object.
The value of "additionalProperties" MUST be a valid JSON Schema.
This keyword determines how child instances validate for objects, and does not directly validate the immediate instance itself.
Validation with "additionalProperties" applies only to the child values of instance names that do not match any names in "properties", and do not match any regular expression in "patternProperties".
For all such properties, validation succeeds if the child instance validates against the "additionalProperties" schema.
Omitting this keyword has the same behavior as an empty schema.
This keyword specifies rules that are evaluated if the instance is an object and contains a certain property.
This keyword's value MUST be an object. Each property specifies a dependency. Each dependency value MUST be an array or a valid JSON Schema.
If the dependency value is a subschema, and the dependency key is a property in the instance, the entire instance must validate against the dependency value.
If the dependency value is an array, each element in the array, if any, MUST be a string, and MUST be unique. If the dependency key is a property in the instance, each of the items in the dependency value must be a property that exists in the instance.
Omitting this keyword has the same behavior as an empty object.
The value of "propertyNames" MUST be a valid JSON Schema.
If the instance is an object, this keyword validates if every property name in the instance validates against the provided schema. Note the property name that the schema is testing will always be a string.
Omitting this keyword has the same behavior as an empty schema.
These keywords work together to implement conditional application of a subschema based on the outcome of another subschema.
These keywords MUST NOT interact with each other across subschema boundaries. In other words, an "if" in one branch of an "allOf" MUST NOT have an impact on a "then" or "else" in another branch.
There is no default behavior for any of these keywords when they are not present. In particular, they MUST NOT be treated as if present with an empty schema, and when "if" is not present, both "then" and "else" MUST be entirely ignored.
This keyword's value MUST be a valid JSON Schema.
This validation outcome of this keyword's subschema has no direct effect on the overall validation result. Rather, it controls which of the "then" or "else" keywords are evaluated.
Instances that successfully validate against this keyword's subschema MUST also be valid against the subschema value of the "then" keyword, if present.
Instances that fail to validate against this keyword's subschema MUST also be valid against the subschema value of the "else" keyword, if present.
If annotations [annotations] are being collected, they are collected from this keyword's subschema in the usual way, including when the keyword is present without either "then" or "else".
This keyword's value MUST be a valid JSON Schema.
When "if" is present, and the instance successfully validates against its subschema, then valiation succeeds against this keyword if the instance also successfully validates against this keyword's subschema.
This keyword has no effect when "if" is absent, or when the instance fails to validate against its subschema. Implementations MUST NOT evaluate the instance against this keyword, for either validation or annotation collection purposes, in such cases.
This keyword's value MUST be a valid JSON Schema.
When "if" is present, and the instance fails to validate against its subschema, then valiation succeeds against this keyword if the instance successfully validates against this keyword's subschema.
This keyword has no effect when "if" is absent, or when the instance successfully validates against its subschema. Implementations MUST NOT evaluate the instance against this keyword, for either validation or annotation collection purposes, in such cases.
This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value.
This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.
This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value.
This keyword's value MUST be a valid JSON Schema.
An instance is valid against this keyword if it fails to validate successfully against the schema defined by this keyword.
Structural validation alone may be insufficient to validate that an instance meets all the requirements of an application. The "format" keyword is defined to allow interoperable semantic validation for a fixed subset of values which are accurately described by authoritative resources, be they RFCs or other external specifications.
The value of this keyword is called a format attribute. It MUST be a string. A format attribute can generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this format attribute and instance SHOULD succeed.
The "format" keyword functions as both an annotation (Section 3.3) and as an assertion (Section 3.2). While no special effort is required to implement it as an annotation conveying semantic meaning, implementing validation is non-trivial.
Implementations MAY support the "format" keyword as a validation assertion. Should they choose to do so:
Implementations MAY add custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support this keyword and/or custom format attributes.
These attributes apply to string instances.
Date and time format names are derived from RFC 3339, section 5.6 [RFC3339].
Implementations supporting formats SHOULD implement support for the following attributes:
Implementations MAY support additional attributes using the other production names defined in that section. If "full-date" or "full-time" are implemented, the corresponding short form ("date" or "time" respectively) MUST be implemented, and MUST behave identically. Implementations SHOULD NOT define extension attributes with any name matching an RFC 3339 production unless it validates according to the rules of that production. [CREF2]There is not currently consensus on the need for supporting all RFC 3339 formats, so this approach of reserving the namespace will encourage experimentation without committing to the entire set. Either the format implementation requirements will become more flexible in general, or these will likely either be promoted to fully specified attributes or dropped.
These attributes apply to string instances.
A string instance is valid against these attributes if it is a valid Internet email address as follows:
Note that all strings valid against the "email" attribute are also valid against the "idn-email" attribute.
These attributes apply to string instances.
A string instance is valid against these attributes if it is a valid representation for an Internet hostname as follows:
Note that all strings valid against the "hostname" attribute are also valid against the "idn-hostname" attribute.
These attributes apply to string instances.
A string instance is valid against these attributes if it is a valid representation of an IP address as follows:
These attributes apply to string instances.
Note that all valid URIs are valid IRIs, and all valid URI References are also valid IRI References.
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid URI Template (of any level), according to [RFC6570].
Note that URI Templates may be used for IRIs; there is no separate IRI Template specification.
These attributes apply to string instances.
To allow for both absolute and relative JSON Pointers, use "anyOf" or "oneOf" to indicate support for either format.
This attribute applies to string instances.

Implementations that validate formats MUST accept at least the subset of ECMA 262 defined in the Regular Expressions [regexInterop] section of this specification, and SHOULD accept all valid ECMA 262 expressions.
Properties defined in this section indicate that an instance contains non-JSON data encoded in a JSON string. They describe the type of content and how it is encoded.
These properties provide additional information required to interpret JSON data as rich multimedia documents.
The content keywords function as both annotations (Section 3.3) and as assertions (Section 3.2). While no special effort is required to implement them as annotations conveying how applications can interpret the data in the string, implementing validation of conformance to the media type and encoding is non-trivial.
Implementations MAY support the "contentMediaType" and "contentEncoding" keywords as validation assertions. Should they choose to do so, they SHOULD offer an option to disable validation for these keywords.
If the instance value is a string, this property defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property. RFC 2045, Sec 6.1 [RFC2045] lists the possible values for this property.
The value of this property MUST be a string.
The value of this property SHOULD be ignored if the instance described is not a string.
The value of this property must be a media type, as defined by RFC 2046 [RFC2046]. This property defines the media type of instances which this schema defines.
The value of this property MUST be a string.
The value of this property SHOULD be ignored if the instance described is not a string.
If the "contentEncoding" property is not present, but the instance value is a string, then the value of this property SHOULD specify a text document type, and the character set SHOULD be the character set into which the JSON string value was decoded (for which the default is Unicode).
Here is an example schema, illustrating the use of "contentEncoding" and "contentMediaType":
{ "type": "string", "contentEncoding": "base64", "contentMediaType": "image/png" }
Instances described by this schema should be strings, and their values should be interpretable as base64-encoded PNG images.
Another example:
{ "type": "string", "contentMediaType": "text/html" }
Instances described by this schema should be strings containing HTML, using whatever character set the JSON string was decoded into (default is Unicode).
The "definitions" keywords provides a standardized location for schema authors to inline re-usable JSON Schemas into a more general schema. The keyword does not directly affect the validation result.
This keyword's value MUST be an object. Each member value of this object MUST be a valid JSON Schema.
{ "type": "array", "items": { "$ref": "#/definitions/positiveInteger" }, "definitions": { "positiveInteger": { "type": "integer", "exclusiveMinimum": 0 } } }
As an example, here is a schema describing an array of positive integers, where the positive integer constraint is a subschema in "definitions":
Schema validation is a useful mechanism for annotating instance data with additional information. The rules for determining when and how annotations are associated with an instance are outlined in section 3.3.
These general-purpose annotation keywords provide commonly used information for documentation and user interface display purposes. They are not intended to form a comprehensive set of features. Rather, additional vocabularies can be defined for more complex annotation-based applications.
The value of both of these keywords MUST be a string.
Both of these keywords can be used to decorate a user interface with information about the data produced by this user interface. A title will preferably be short, whereas a description will provide explanation about the purpose of the instance described by this schema.
There are no restrictions placed on the value of this keyword. When multiple occurrences of this keyword are applicable to a single sub-instance, implementations SHOULD remove duplicates.
This keyword can be used to supply a default JSON value associated with a particular schema. It is RECOMMENDED that a default value be valid against the associated schema.
The value of these keywords MUST be a boolean. When multiple occurrences of these keywords are applicable to a single sub-instance, the resulting value MUST be true if any occurrence specifies a true value, and MUST be false otherwise.
If "readOnly" has a value of boolean true, it indicates that the value of the instance is managed exclusively by the owning authority, and attempts by an application to modify the value of this property are expected to be ignored or rejected by that owning authority.
An instance document that is marked as "readOnly for the entire document MAY be ignored if sent to the owning authority, or MAY result in an error, at the authority's discretion.
If "writeOnly" has a value of boolean true, it indicates that the value is never present when the instance is retrieved from the owning authority. It can be present when sent to the owning authority to update or create the document (or the resource it represents), but it will not be included in any updated or newly created version of the instance.
An instance document that is marked as "writeOnly" for the entire document MAY be returned as a blank document of some sort, or MAY produce an error upon retrieval, or have the retrieval request ignored, at the authority's discretion.
For example, "readOnly" would be used to mark a database-generated serial number as read-only, while "writeOnly" would be used to mark a password input field.
These keywords can be used to assist in user interface instance generation. In particular, an application MAY choose to use a widget that hides input values as they are typed for write-only fields.
Omitting these keywords has the same behavior as values of false.
The value of this keyword MUST be an array. There are no restrictions placed on the values within the array. When multiple occurrences of this keyword are applicable to a single sub-instance, implementations MUST provide a flat array of all values rather than an array of arrays.
This keyword can be used to provide sample JSON values associated with a particular schema, for the purpose of illustrating usage. It is RECOMMENDED that these values be valid against the associated schema.
Implementations MAY use the value(s) of "default", if present, as an additional example. If "examples" is absent, "default" MAY still be used in this manner.
JSON Schema validation defines a vocabulary for JSON Schema core and concerns all the security considerations listed there.
JSON Schema validation allows the use of Regular Expressions, which have numerous different (often incompatible) implementations. Some implementations allow the embedding of arbitrary code, which is outside the scope of JSON Schema and MUST NOT be permitted. Regular expressions can often also be crafted to be extremely expensive to compute (with so-called "catastrophic backtracking"), resulting in a denial-of-service attack.
Implementations that support validating or otherwise evaluating instance string data based on "contentEncoding" and/or "contentMediaType" are at risk of evaluating data in an unsafe way based on misleading information. Applications can mitigate this risk by only performing such processing when a relationship between the schema and instance is established (e.g., they share the same authority).
Processing a media type or encoding is subject to the security considerations of that media type or encoding. For example, the security considerations of RFC 4329 Scripting Media Types [RFC4329] apply when processing JavaScript or ECMAScript encoded within a JSON string.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC2045] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996. |
| [RFC2046] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996. |
| [RFC2673] | Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999. |
| [RFC3339] | Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. |
| [RFC3987] | Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005. |
| [RFC4291] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006. |
| [RFC5322] | Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. |
| [RFC5890] | Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010. |
| [RFC5891] | Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010. |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012. |
| [RFC6531] | Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012. |
| [RFC6901] | Bryan, P., Zyp, K. and M. Nottingham, "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013. |
| [RFC7159] | Bray, T., The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [ecma262] | ECMA 262 specification" | , "
| [relative-json-pointer] | Luff, G. and H. Andrews, "Relative JSON Pointers", Internet-Draft draft-handrews-relative-json-pointer-01, November 2017. |
| [json-schema] | Wright, A. and H. Andrews, "JSON Schema: A Media Type for Describing JSON Documents", Internet-Draft draft-handrews-json-schema-01, November 2017. |
| [RFC4329] | Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006. |
Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff for their work on the initial drafts of JSON Schema.
Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, and Denis Laxalde for their submissions and patches to the document.
[CREF3]This section to be removed before leaving Internet-Draft status.


[viewBag] title = "Become an Intern or Volunteer!" url = "/for-individuals/become-a-volunteer" layout = "title-text-static" is_hidden = 0 navigation_hidden = 0 robot_index = "index" robot_follow = "follow" ==
Kiron offers a range of volunteering opportunities, e.g. helping our students with online tutoring or forum guidance, supporting the fundraising team in grant writing, designing communication materials, programming new platform features, organizing regional students events, matching curriculums and much more. Your support is needed at our German offices in Berlin and Munich, in our country teams in Istanbul, Paris and Amman as well as in our student regional groups in Aachen, Bielefeld, Cologne, Lüneburg and Passau. If you bring in special skills, e.g. programming or tutoring, it might also be possible to volunteer remotely from your location.
Please help us find the right volunteer spot in our team by filling out this form and telling us more about your interests, skills and availability: Apply as a volunteer!
Contact
Johanna Salewsky, Volunteer Manager
You are looking for an internship to improve your skills and to get insights in how a social start-up operates?  We are always looking for talented interns to join our teams in the areas of Marketing/Communications, Human Resources, Business Development & Fundraising, Curriculum Development, Legal & Organisation, Event Management, Student Services in our Berlin and Munich offices.
Please check out our currently open internships or contact Alice with your initial application (CV+Motivation letter)!
(Please note that we can only offer internships if mandatory for your university studies -“Pflichtpraktikum”- or if meant as an orientation between studies -“Orientierungspraktikum”-)_With our limited budget we’re unfortunately unable to pay salaries.
If you would like to find out more, please contact:
Alice Schmidt, Intern Manager


--- layout: base title: "Calvin Yu - Resume" subtitle: "Embedded software engineer with a M.S. in Computer Science and a B.S. in Computer Science. Currently pursuing a doctorate in Electrical Engineering." show-avatar: true nav-short: false ---


Class DatabaseObject
Class to represent a database through which the user can connect to and query from.
Inherited Members
Namespace: DatabaseConnector
Assembly: DatabaseConnector.dll
Syntax
public abstract class DatabaseObject
Constructors
| Improve this Doc View SourceDatabaseObject()
Initializes a new instance of the DatabaseObject class.
Declaration
public DatabaseObject()
DatabaseObject(ILogger)
Initializes a new instance of the DatabaseObject class.
Declaration
public DatabaseObject(ILogger logger)
Parameters
| Type | Name | Description |
|---|---|---|
| Microsoft.Extensions.Logging.ILogger | logger | The logger to be used in this library. |
DatabaseObject(String)
Initializes a new instance of the DatabaseObject class.
Declaration
public DatabaseObject(string connectionString)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | connectionString | The connection string to be used to connect to the database. |
DatabaseObject(String, ILogger)
Initializes a new instance of the DatabaseObject class.
Declaration
public DatabaseObject(string connectionString, ILogger logger)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | connectionString | The connection string to be used to connect to the database. |
| Microsoft.Extensions.Logging.ILogger | logger | The logger to be used in this library. |
Properties
| Improve this Doc View SourceConnected
Gets or sets a value indicating whether gets or sets the state of the database.
Declaration
protected bool Connected { get; set; }
Property Value
| Type | Description |
|---|---|
| System.Boolean |
ConnectionString
Gets or sets the connection string to connect to the database.
Declaration
protected string ConnectionString { get; set; }
Property Value
| Type | Description |
|---|---|
| System.String |
Logger
Gets or sets the logger to be used by the database.
Declaration
protected ILogger Logger { get; set; }
Property Value
| Type | Description |
|---|---|
| Microsoft.Extensions.Logging.ILogger |
Methods
| Improve this Doc View SourceConnect()
Connects to the database.
Declaration
public abstract bool Connect()
Returns
| Type | Description |
|---|---|
| System.Boolean | if the database has been successfully connected to.
|
Disconnect()
Disconnects from the database.
Declaration
public abstract bool Disconnect()
Returns
| Type | Description |
|---|---|
| System.Boolean | if the database has been successfully disconnected from.
|
ExecuteNonQuery(String)
Executes the given query that does not return any data (e.g. update, insert, delete).
Declaration
public abstract bool ExecuteNonQuery(string nonQuery)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | nonQuery | Query to execute. |
Returns
| Type | Description |
|---|---|
| System.Boolean | if query was successfully executed.
|
ExecuteQuery(String)
Executes the given query that retrieves data from the database.
Declaration
public abstract List<List<object>> ExecuteQuery(string query)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | query | Query to execute. |
Returns
| Type | Description |
|---|---|
| System.Collections.Generic.List<System.Collections.Generic.List<System.Object>> | Data queried from the database. |
IsConnected()
Returns whether or not a connection has been established to the database.
if the database has been connected totrue
Declaration
public abstract bool IsConnected()
Returns
| Type | Description |
|---|---|
| System.Boolean | if the database has been connected to.
|


First, get all the files, either as a zip archive or a gzipped tar-file and unpack them. Now, start up Matlab (version 5 or higher). Make
sure that the toolbox is in your path. This can be done simply by
cd
'ing to the correct directory.
Alternatively,
if you have unpacked them into
directory /users/rich/m_map
(and /users/rich/m_map/private
),
then you can add this to your search path:
path(path,'/users/rich/m_map');or
addpath /users/rich/m_mapTo follow along with this document, you would then use a Web-browser to open
file:/users/rich/m_map/map.html
, that
is, this HTML document.
(Note: you may want to install M_Map as a toolbox accessible to all users. To do this, unpack the files into $MATLAB/toolbox/m_map, and add that directory to the list defined in $MATLAB/toolbox/local/pathdef.m).
Instructions for installing the (optional) high-resolution bathymetry database are given in Section 9 , and instructions for installing the (optional) high-resolution GSHHS coastline database is given in Section 10 . However, we should first check that the basic setup is OK.
To see an example map, try this:
m_proj('oblique mercator'); m_coast; m_grid;This is a line map of the Oregon/British Columbia coast, using an Oblique Mercator projection (A few more complex maps can be generated by running the demo function
m_demo
).
The first line initializes the projection. Defaults are set for the different projection, so you can easily see what a specific projection looks like, but all projections have a number of optional parameters as well. To get the same map without using the defaults, you would use
m_proj('oblique mercator','longitudes',[-132 -125], ... 'latitudes',[56 40],'direction','vertical','aspect',.5);The exact meanings of the various options is given in Section 2 . However, notice that longitudes are specified using a signed notation - East longitudes are positive, whereas West longitudes are negative (Also note that a decimal degree notation is used, so that a longitude of 120 30'W is specified as -120.5).
The second line draws a coastline, using the 1/4 degree database. Coastlines with greater
resolution can be drawn, using your own database (see also Section 7 ). m_coast
can be called with various line parameters. For example,
m_coast('linewidth',2,'color','r');draws a thicker red coastline. Filled coastlines can also be drawn, using the
'patch'
option (followed by any of the usual PATCH property/value pairs).
m_coast('patch',[.7 .7 .7],'edgecolor','none');draws a coastline with a gray fill and no border.
The third line superimposes a grid. Although there are many possible options that can be used to customize the appearance of the grid, defaults can always be used (as in the example). These options are discussed in Section 4 . You can get a list of the options using the GET syntax:
m_grid getwhich acts somewhat like the
get(gca)
syntax for regular plots.
Finally, suppose you want to show and label the location of, say, a mooring at 129W, 48 30'N.
[X,Y]=m_ll2xy(-129,48.5); line(X,Y,'marker','square','markersize',4,'color','r'); text(X,Y,' M5','vertical','top');
m_ll2xy
(and its inverse m_xy2ll
) convert from longitude/latitude coordinates to those of the
projection. Various clipping options can also be specified in converting to projection
coordinates. If you are willing to accept default clipping setting, you can
use the built-in functions m_line
and m_text
:
m_line(-129,48.5,'marker','square','markersize',4,'color','r'); m_text(-129,48.5,' M5','vertical','top');
Finally (!), we may want to alter the grid details slightly. Note that, a given map must only be initialized once.
clf m_coast('patch',[.7 .7 .7],'edgecolor','none'); m_grid('xlabeldir','end','fontsize',10); m_line(-129,48.5,'marker','square','markersize',4,'color','r'); m_text(-129,48.5,' M5','vertical','top');
In order to get a list of the current projections,
m_proj getor
m_proj('get');Which currently return the following list:
Available projections are: Stereographic Orthographic Azimuthal Equal-area Azimuthal Equidistant Gnomonic Satellite Albers Equal-Area Conic Lambert Conformal Conic Mercator Miller Cylindrical Equidistant Cylindrical Oblique Mercator Transverse Mercator Sinusoidal Gall-Peters Hammer-Aitoff Mollweide UTMIf you want details about the possible options for any of these projections, add its name to the above command, e.g.
m_proj('get','stereographic'); 'Stereographic' <,'lon<gitude>',center_long> <,'lat<itude>', center_lat> <,'rad<ius>', ( degrees | [longitude latitude] )> <,'rec<tbox>', ( 'on' | 'off' )>You can also get details about the current projection. For example, in order to see what the default parameters are for the sinusoidal projection, we first initialize it, and then use the
'set'
option:
m_proj('sinusoidal'); m_proj set Current mapping parameters - Projection: Sinusoidal (function: mp_tmerc) longitudes: -90 30 (centered at -30) latitudes: -65 65 Rectangular border: offIn order to initialize a projection, you usually specify some location parameters that define the geometry of the projection (longitudinal limits, central parallel, etc.), as well as parameters that define the extent of the map (whether it is in a rectangular axis, what the border points are, etc.). These vary slightly from projection to projection.
Two useful properties for projections are (1) the ability the preserve angles for differentially small regions, and (2) the ability to preserve area. Projections satisfying the first condition are called conformal , those satisfying the second are called equal-area . No projection can be both. Many projections (especially global projections) are neither, instead an attempt has been made to aesthetically balance the errors in both conditions.
Note: All projections (except UTM) are currently spherical rather than ellipsoidal. It is unlikely that this will be a problem in normal usage.
<,'lon<gitude>',center_long>
<,'lat<itude>', center_lat>
<,'rad<ius>', ( degrees | [longitude latitude] )>
<,'rec<tbox>', ( 'on' | 'off' | 'circle' )>
radius
for the map, the viewpoint altitude is specified:
<,'alt<itude>', altitude_fraction >
These maps are usually drawn with rectangular boundaries (with the exception of the sinusoidal and sometimes the transverse mercator).
<,'lon<gitude>',( [min max] | center)>
<,'lat<itude>', ( maxlat | [min max])>
<,'lon<gitude>',[ G1 G2 ]>
<,'lat<itude>', [ L1 L2 ]>
<,'asp<ect>',value>
<,'dir<ection>',( 'horizontal' | 'vertical' )
<,'lon<gitude>',[min max]>
<,'lat<itude>',[min max]>
<,'clo<ngitude>',value>
<,'rec<tbox>', ( 'on' | 'off' )>
<,'zon<e>', value 1-60>
<,'hem<isphere>',value 0=N,1=S>
'normal'
,
a spherical earth of radius 1 unit, but other options
can also be chosen using the following property:
<,'ell<ipsoid>', ellipsoid>
m_proj('get','utm')
.
The big difference between UTM and all
the other projections is that for ellipsoids other than 'normal'
the projection coordinates are in meters of easting and
northing. To take full advantage of this it is often useful to call m_proj
with 'rectbox'
set to 'on'
and not to use the long/lat
grid generated by m_grid
(since the regular matlab grid will be in units
of meters).
<,'lon<gitude>',[min max]>
<,'lat<itude>',[min max]>
<,'clo<ngitude>',value>
<,'par<allels>',[lat1 lat2]>
<,'rec<tbox>', ( 'on' | 'off' )>
'off'
.
m_proj('mollweide'); m_coast('patch','r'); m_grid('xaxislocation','middle');
If you are plotting something with a large north/south extent, but not very wide (say, North and South America, or the North and South Atlantic), then the Sinusoidal or Mollweide projections will look pretty good. Another choice is the Transverse Mercator, although that is usually used only for very large-scale maps.
For smaller areas within one hemisphere or other (say, Australia, the United States, the Mediterranean, the North Atlantic) you might pick a conic projection. The differences between the two available conic projections are subtle, and if you don't know much about projections it probably won't make much difference which one you use.
If you get smaller than that, it doesn't matter a whole lot which projection you use. One projection I find useful in many cases is the Oblique Mercator, since you can align it along a long (but narrow) coastal area. If map limits along lines of longitude/latitude are OK, use a Transverse Mercator or Conic Projection. The UTM projection is also useful.
Polar areas are traditionally mapped using a Stereographic projection, since for some reason it looks nice to have a "bullseye" pattern of latitude lines.
If you want to get a quick idea of what any projection looks like, default parameters for all functions are set for a "typical" usage, i.e. to get a quick idea of what any projection looks like, you can do so without having to figure out a lot of numerical values:
m_proj('stereographic'); % Example for stereographic projection m_coast; m_grid;
m_scale
primitive for this - for a 1:250000 map, call
m_scale(250000);after you have drawn everything (Be careful - a 1:250000 map of the world is a lot bigger than 8.5"x11" sheet of paper).
This option is usually only useful for large-scale maps, i.e. maps of very small areas).
If you wish to know the current scale, calling m_scale
without
any parameters will calculate and return that value.
To return to the default scaling call m_scale('auto')
.
(PS - If you do want to find distances from Bangkok to anywhere, plot an azimuthal equidistant projection of the world centered on Bangkok (13 44'N, 100 30'E), and choose a fairly small scale, like 1:200,000,000). Another option would be to use range rings, see example 11.
M_Map includes two fairly simple databases for coastlines and global elevation data. Highly-detailed databases are not included in this release because they are a) extremely large and b) extremely time-consuming to process (loops are inherently involved). If more detailed maps are required, section 9 and section 10 give instructions on how to add some freely-available high-resolution datasets. Read section 7 and section 8 if you want to add your own coastline/bathymetry data.
M_Map includes a 1/4 degree resolution coastline database. This is suitable for maps
covering large portions of the globe, but is noticeably coarse for many large-scale
applications. Users not satisfied with their regional map are directed to
section 7 and/or section 10
for more information on creating and using high-resolution
coastlines.
The M_Map database is accessed using the m_coast
function. Coastlines
can be drawn as simple lines, using
m_coast('line', ...optional line arguments );or
m_coast( optional line arguments );where the optional arguments are all the standard arguments for specifying line style, width, color, etc. Coastlines can also be drawn as filled patches using
m_coast('patch', ...optional patch arguments );where the optional trailing arguments are the standard patch properties. For example,
m_coast('patch',[.7 .7 .7],'edgecolor','g');draws gray land, outlined in green. When patches are being drawn, lakes and inland seas are given the axes background colour.
Note that line coastlines are usually drawn rather rapidly. Filled coastlines take considerably more time to generate (because map limits are not necessarily rectangular, clipping must be accomplished in m-files).
M_Map can access a 1-degree resolution global elevation database (actually, this database is
is included in the Matlab distribution, used by of $MATLAB/toolbox/matlab/demos/earthmap.m
).
A contour map of elevations at default levels can be drawn using
m_elev;Different levels can also be specified:
m_elev('contour',LEVELS, optional contour arguments);For example, if you want all the contours to be dark blue, use:
m_elev('contour',LEVELS,'edgecolor','b');Filled contours are also possible:
m_elev('contourf',LEVELS, optional contourf arguments);Finally, if you want to simply extract the elevation data for your own purposes,
[Z,LONG,LAT]=m_elev([LONG_MIN LONG_MAX LAT_MIN LAT_MAX]);returns rectangular matrices for depths Z at locations LONG,LAT.
m_proj('Lambert'); m_coast; m_grid;to get a Lambert conic projection of North America. Now try
m_ungridThe coastline is still there, but the grid has disappeared and the axes shows raw X/Y projection coordinates. Now, try this:
m_grid('xtick',10,'tickdir','out','yaxislocation','right','fontsize',7);The various options that can be changed are:
'box',( 'on' | 'off' | 'fancy' )
'on'
, the default, is a a simple line. Two
types of fancy outline boxes are available. If 'tickdir'
is 'in'
,
then alternating black and white patches are made (see example 2).
If 'tickdir'
is set to 'out'
, then a more complex line pattern
is drawn (see example 6).
Fancy boxes are in general only available for maps bounded
by lat/long limits (i.e. not for azimuthal projections), but if this option is
chosen inappropriately a warning message is issued.
'xtick',( num | [value1 value2 ...])
'ytick'
property.
'xticklabels',[label1;label2 ...]
'yticklabels'
property
'xlabeldir', ( 'middle' | 'end' )
'ylabeldir'
property.
'ticklen',value
'tickdir',( 'in' | 'out' )
'box'
is
set to 'fancy'
, this specifies the form of the fancy outline box.
'color',colorspec
'linewidth', value
'linestyle', ( linespec | 'none' )
'fontsize',value
'fontname',name
'XaxisLocation',( 'bottom' | 'middle' | 'top' )
'YaxisLocation',( 'left' | 'middle' | 'right' )
title
and
x/ylabel
functions in the usual way (this is a change from v1.0 in which
the 'visible' property had
to be explicitly set to 'on'; this is now done within m_grid).
The purpose of this package is to allow you to map your own data! Once a suitable grid and (possibly) a coastline have been chosen, you can add your own lines, text, or contour plots using built-in M_Map drawing functions which handle the conversion from longitude/latitude coordinates to projection coordinates. These drawing functions are very similar to the standard Matlab plotting functions, and are described in the next section.
Sometimes you may want to convert between longitude/latitude and projection coordinates
without immediately plotting the data. This might happen if you want to interactively
select points using ginput
, or if you want to draw labels tied to a
specific point on the screen rather than a particular longitude/latitude. Projection
conversion routines are described in sections 5.2 and
5.3. Once raw longitude/latitude coordinates are converted into
projection coordinates, standard Matlab plotting functions can be used.
Maps are drawn to fit within the boundaries of the plot axes. Thus their scale
is somewhat arbitrary. If you are interested in making a map to a given
scale, e.g. 1:200000 or something like that, you can do so by using the
m_scale
primitive, see section 2.6 .
The data units are the projection coordinates, which are distances expressed
as a fraction of earth radii. To get a map "distance" between two points,
use the Cartesian distance between the points in the projection coordinate
system and multiply by your favourite value for the earth's radius, usually
around 6370 km (exception - the UTM projection uses coordinates of northing and
easting in meters, so no conversion is necessary).
Caution: One problem that sometimes occurs is that data does not appear on the plot due to ambiguities in longitude values. For example, if plot longitude limits are [-180 180], a point with a longitude of, say, 200, may not appear in cylindrical and conic projections. This is not a bug. Handling the clipping in "wrapped around" curves requires adding points (rather than just moving them) and is therefore incompatible with various other requirements (such as keeping input and output matrices the same size in the conversion routines described below).
line, text, quiver, patch,
contour, and contourf
with M_Map equivalents that recognize
lontgitude/latitude coordinates by prepending "m_" to the function name. For example,
m_line(LONG,LAT,...line properties) % draw a line on a map m_quiver(LONG,LAT,U,V,S) % A quiver plot m_text(LONG,LAT,'string') % Text m_patch(LONG,LAT,..patch properties) % Patches.Each of these functions will handle the coordinate conversion internally, and will return a vector of handles to the graphic objects if desired. The only difference between these functions and the standard Matlab functions is that the first two arguments MUST be longitude and latitude.
Data gridded in longitude and latitude can also be contoured:
m_contour(LONG,LAT,VALUES) m_contourf(LONG,LAT,VALUES)Again, these functions will return handles to graphics objects, allowing (for example) the drawing of labelled contours:
[cs,h]=m_contour(LONG,LAT,VALUES) clabel(cs,h,'fontsize',6);
Fancy arrows (i.e. with width, head shape, and colour specifications) can be generated using
m_vec.m
. See the on-line help for more details about the use of m_vec
.
m_track
.
m_proj('UTM','long',[-72 -68],'lat',[40 44]); m_gshhs_i('color','k'); m_grid('box','fancy','tickdir','out'); % fake up a trackline lons=[-71:.1:-67]; lats=60*cos((lons+115)*pi/180); dates=datenum(1997,10,23,15,1:41,zeros(1,41)); m_track(lons,lats,dates,'ticks',0,'times',4,'dates',8,... 'clip','off','color','r','orient','upright');
m_track
, and
the different options for setting fontsize, tick spacing, date formats, etc.
While fiddling with the various parameters, it is often handy to be able to erase the plotted tracks without erasing the coastline and grid. This can be done using
m_ungrid trackor
m_ungrid('track')
m_range_ring
,
which has 3 required calling parameters: LONG, LAT, RANGE, followed by any number of
(optional) line specification property/value pairs. Example 11
illustrates how to use m_range_ring
.
[X,Y]=m_ll2xy(LONG,LAT, ...optional clipping arguments )where LONG, LAT, X, and Y are matrices of the same size. Projection coordinates are equal to true distances near the center of the map, and are expressed as fractions of an earth radius. To get a distance, multiply by the radius of the earth (about 6370km). The exception is the UTM projection which provides coordinates of northing and easting in meters.
The possible clipping arguments are
'clip','on'
'clip','off'
'clip','point'
'clip','patch'
[LONG,LAT]=m_ll2xy(X,Y)There are no options.
For ideas on how to make more complex plots, see the Examples.
These plots are also included in the function m_demo
.
Once a given map includes several elements a certain amount of fiddling is usually necessary
to satisfy the natural human urge to give the image a certain aesthetic quality. If the image
includes complicated coastlines which take a long time to draw
(e.g. those discussed below) than clearing the figure and
redrawing soon becomes tedious. The m_ungrid
command introduced above can be used
to selectively remove parts of the figure. For example:
m_proj('lambert','long',[-160 -40],'lat',[30 80]); m_coast; m_range_ring(-123,49,[1e3:1e3:10e3],'color','r');draws range rings at 1000km increments from my office. But I am unsatisfied with this, and want to redraw using only 200km increments. I can remove the effects of
m_range_ring
and redraw using:
m_ungrid range_ring m_range_ring(-123,49,[200:200:2000],'color','r');In general the results of
m_ANYTHING
can be deleted by calling
m_ungrid ANYTHING
.
m_ungrid
can recognize and delete specific elements by searching
the 'tag'
property of all plot elements, which is set by the various
different M_Map routines.
If you are interested in a particular area and want a higher-resolution coastline than
that used by m_coast
, the best procedure is to
m_ll2xy
, and plot.
load coast.dat m_line(coast(:,1),coast(:,2));Filled coastlines will require more work. You should first read the instructions there on joining the coastline data into continuous segments. If you are lucky, (i.e. no lakes or anything else), you may achieve success with
load coast.dat [X,Y]=m_ll2xy(coast(:,1),coast(:,2),'clip','patch'); k=[find(isnan(X(:,1)))]; for i=1:length(k)-1, x=coast([k(i)+1:(k(i+1)-1) k(i)+1],1); y=coast([k(i)+1:(k(i+1)-1) k(i)+1],2); patch(x,y,'r'); end;If this does not work, read the comments in
private/mu_coast
, orient the curves
in the desired fashion, and use m_usercoast
to load your own data.
Files containing political boundaries for various countries and US states can be
downloaded from
http://www.maproom.psu.edu/cgi-bin/ian/points/index.cgi. Once downloaded
to your machine use
m_plotbndry
to access and plot the desired boundary. For example,
if you downloaded various US states into a subdirectory "states:,
m_plotbndry('states/arizona','color,'r')would plot arizona on the current map.
A number of global and regional topography databases are available at NCAR . Several are available for free from their ftp site.
As long as the data is stored in a mat-file as a rectangular matrix in longitude/latitude,
then m_contour
or m_contourf
can be used to plot
that data.
A recent new bathymetry with approximately 1km resolution in lower latitude areas is being used by many people. This dataset is described at http://topex.ucsd.edu/marine_topo/text/topo.html and is available as a 134Mb binary file at ftp://topex.ucsd.edu/pub/global_topo_2min/topo_6.2.img . The authors have included an m-file (mygrid_sand.m) which can extract portions of the data. Once this database (and the m-file) is installed on your computer, you can use it in M_Map very easily. A typical usage is as follows:
% Extract data [elevations,lat,lon]=mygrid_sand([lat_south lat_north long_west long_east]); % Use in M_Map command m_contour(lon,lat,elevations);For some projections, you must make sure that the 'lon' values returned by
mygrid_sand.m
fall within the range used in this projection
(i.e. you may have to add/subtract 360). This seems to happen all the time
for areas in the west (i.e. negative longitudes), if you forget this
you often end up with bewildering error messages about empty vectors!
For many purposes the elevation database accessed by M_Map provides adequate resolution. However, there are also many cases when more detail is desired. I have not included a higher-resolution database because it would greatly increase the size of the package. However, v1.2 includes m-files to access and plot a popular global 5-minute bathymetry/topography database, after a few minutes of work.
This section provides instructions on how to download
TerrainBase, and convert
it from a 56Mb ASCII file to a 18Mb binary file using m_tba2b.m
. It
is then straightforward to access and plot bathymetry from this file using
m_tbase.m
, which is in every way functionally identical to
m_elev
(see Section 3.2).
TerrainBase is also available on CDrom, and is also
commonly stored in netcdf (or other) binary format somewhere on many academic networks. If
you modify m_tbase.m
to access data from one of these
sources, let me know!
How to install TerrainBase:
m_tba2b('PATHNAME')
to store the resulting 18Mb binary
file as PATHNAME/tbase.int
.
tbase
.
PATHNAME
setting in m_tbase
to
point to the location of this file.
m_proj('lambert','lon',[-10 20],'lat',[33 48]); m_tbase('contourf'); m_grid('linestyle','none','tickdir','out','linewidth',3);
When drawing maps there is always a tradeoff between the execution time of the generating program and the resolution of the resulting map. Included in M_Map is a 1/4 degree coastline database which can be used to generate very fast maps, with adequate resolution for many purposes.
However, it is often desirable to be able to make detailed maps of limited geographic areas. For this purpose a higher-resolution coastline database is necessary. I have not included such a database in M_Map because it would greatly increase the size of the package. However, I have included m-files to access and use a popular high-resolution database called GSHHS
As distributed, GSHHS consists of a hierarchical set of databases at different resolutions. The lowest or "crude" resolution is not as good as the M_Map database, although it contains many more inland lakes. The "high" resolution consists of points about 200m apart. There is also an even finer "full" resolution. You can install part or all of the database (depending on how much disk space you have available). The "full" resolution occupies 90Mb of disk space, and successively coarser resolutions are smaller by about 1/4. Thus "high" resolution occupies 21Mb, "intermediate" uses 6Mb, and "low" uses 1.1Mb (one reason for not always using "high" resolution is that the entire 90Mb database must be read and processed each call, which may take some time).
How to install GSHHS:
gshhs_c.b.gz,
gshhs_l.b.gz, gshhs_i.b.gz
and/or gshhs_h.b.gz
in a
convenient directory. One useful place is in m_map/private
.
m_map/private
,
you must edit the FILNAME
settings in m_gshhs_c.m,
m_gshhs_l.m, m_gshhs_i.m, m_gshhs_h.m
and/or m_gshhs_f.m
to point to the appropriate files.
m_coast
( Section 3 ). For example, to draw a gray-filled
high-resolution coastline,
m_gshhs_h('patch',[.5 .5 .5]);is sufficient. However, execution times may be very, very long, as the entire database must be searched and processed. I would not recommend trying to draw world maps with the intermediate or high-resolution coastlines! There are two ways to speed this up. The first is merely to use a lower-resolution database, with fewer points. The second is useful if you are going to be repeatedly drawing a map (because, for example, it's the base figure for your work). In this case I recommend that you save an intermediate processed (generally smaller) file as follows:
m_proj ... % set up projection parameters % This command does not draw anything - it merely processes the % high-resolution database using the current projection parameters % to generate a smaller coastline file called "gumby" m_gshhs_h('save','gumby'); % Now we can draw a few maps of the same area much more quickly figure(1); m_usercoast('gumby','patch','r'); m_grid; figure(2); m_usercoast('gumby','linewidth',2,'color','b'); m_grid('tickdir','out','yaxisloc','left'); etc.
> Warning: Divide by zero.messages. This is due to a bug in Matlab (actually due to the compiler TMW used) that results in an incorrect warning flag being set when dividing some numbers by NaN. You can safely ignore these errors and wait for v5.2
print
command.
In order to avoid this, set the figure background to white, i.e.
set(gcf,'color','white')
However, if you print the figure, the resulting postscript file (or plot) will show the colours as expected. This appears to be a bug of some sort in Matlab.
If you want to see the colours in Matlab itself, try this:
set(findobj('tag','m_grid_color'),'facecolor','none')


Jamison McGrath:
Project Role:
Planning and coordination,
Style and artistic design,
User experience and sight
functionality.
About Me:
I'm a 30 year old from Brisbane Australia that started plumbing at the age of 16,
Due to a workplace accident I suffered a life changing injury,
This unfortunate event has opened up a new opportunity for me to learn a new skill set,
My coding journey has already showed me many areas where my learned and natural ability's will lead me to
find a great level of success and make me an invaluable member of any future team I become a member of.
Charlie Fadness:
Project Role:
Backend planing and development.
Bring puesdo to life.
Lead programmer
About Me:
I am a massage therapist for over 9 years now, from my love of baking, I learned that I tend to be very specific and have a logical mindset. From there, after discussing coding with friends and learning python, I knew where my path would go. From my expierence at Code Fellows, I found I love helping and teaching as this makes me have to keep thinking of the subjects from a different mindset as I always try to explain things from a different aspect to keep learning new things everyday!
Mark Thanadabouth:
Project Role:
Backend programming.
About Me:
I am an Army veteran who is currently a student at Code Fellows Seattle,
I'm originally from Chicago, IL. and have a dual degree in Digital Audio Engineering and Electronic/MIDI
Music Production.
I then became a personal trainer for a couple of years before deciding
to become a software developer.
Brian Nelson
Project Role:
Support and conflict handler.
About Me:
Retired Soldier, full-time husband, animal rescue co-founder, race director, Veteran & Mil Spouse employment agency, TEDx speaker, insatiably curious...


GlueGen is a tool which automatically generates the Java and JNI code necessary to call C libraries. It reads as input ANSI C header files and separate configuration files which provide control over many aspects of the glue code generation. GlueGen uses a complete ANSI C parser and an internal representation (IR) capable of representing all C types to represent the APIs for which it generates interfaces. It has the ability to perform significant transformations on the IR before glue code emission. GlueGen is currently powerful enough to bind even low-level APIs such as the Java Native Interface (JNI) and the AWT Native Interface (JAWT) back up to the Java programming language. GlueGen is currently used to generate the JOGL interface to the OpenGL 3D graphics API and the JOAL interface to the OpenAL audio library.
The preliminary GlueGen manual is on-line, which describes how to acquire, build and use GlueGen.
The GlueGen discussion forum and mailing lists are available for discussions on how to use and develop the tool.


ACA Health Plots |
Plots of ACA housing temperature, CCD temperature, and DAC control level. Data is only available during perigee passes or other 8x8 ERs. Datestart and datestop correspond to the time range when 8x8 ACA telemetry is available for all required slots.


Credits
Go back
ChatBox Design
Chat bubbles design came from
ChatBox design
Sticky Footer from
Awesome post


|
TensorRT
<IP_ADDRESS>
|
A Scale layer in a network definition. More...
#include <NvInfer.h>
Public Member Functions | |
| virtual void | setMode (ScaleMode mode)=0 |
| Set the scale mode. More... | |
| virtual ScaleMode | getMode () const =0 |
| Set the scale mode. More... | |
| virtual void | setShift (Weights shift)=0 |
| Set the shift value. More... | |
| virtual Weights | getShift () const =0 |
| Get the shift value. More... | |
| virtual void | setScale (Weights scale)=0 |
| Set the scale value. More... | |
| virtual Weights | getScale () const =0 |
| Get the scale value. More... | |
| virtual void | setPower (Weights power)=0 |
| Set the power value. More... | |
| virtual Weights | getPower () const =0 |
| Get the power value. More... | |
| virtual int | getChannelAxis () const =0 |
| Get the channel axis. More... | |
| Public Member Functions inherited from nvinfer1::ILayer | |
| virtual LayerType | getType () const =0 |
| Return the type of a layer. More... | |
| virtual void | setName (const char *name)=0 |
| Set the name of a layer. More... | |
| virtual const char * | getName () const =0 |
| Return the name of a layer. More... | |
| virtual int | getNbInputs () const =0 |
| Get the number of inputs of a layer. | |
| virtual ITensor * | getInput (int index) const =0 |
| Get the layer input corresponding to the given index. More... | |
| virtual int | getNbOutputs () const =0 |
| Get the number of outputs of a layer. | |
| virtual ITensor * | getOutput (int index) const =0 |
| Get the layer output corresponding to the given index. More... | |
| virtual void | setInput (int index, ITensor &tensor)=0 |
| replace an input of this layer with a specific tensor More... | |
| virtual void | setPrecision (DataType dataType)=0 |
| Set the computational precision of this layer. More... | |
| virtual DataType | getPrecision () const =0 |
| get the computational precision of this layer More... | |
| virtual bool | precisionIsSet () const =0 |
| whether the computational precision has been set for this layer More... | |
| virtual void | resetPrecision ()=0 |
| reset the computational precision for this layer More... | |
| virtual void | setOutputType (int index, DataType dataType)=0 |
| Set the output type of this layer. More... | |
| virtual DataType | getOutputType (int index) const =0 |
| get the output type of this layer More... | |
| virtual bool | outputTypeIsSet (int index) const =0 |
| whether the output type has been set for this layer More... | |
| virtual void | resetOutputType (int index)=0 |
| reset the output type for this layer More... | |
A Scale layer in a network definition.
This layer applies a per-element computation to its input:
output
= (input*
scale
+ shift
)^ power
The coefficients can be applied on a per-tensor, per-channel, or per-element basis.
The output size is the same as the input size.
|
pure virtual |
Get the channel axis.
The value is the index of the channel axis in the input tensor's dimensions. All dimensions after the channel axis are assumed to be spatial dimensions, and the only spatial dimensions in the tensor. The number of spatial dimensions is thus getDimensions().nbDims - channelAxis - 1. Supported numbers of spatial dimensions are 2 and 3 for 2d and 3d scale layers respectively.
|
pure virtual |
Set the scale mode.
|
pure virtual |
Get the power value.
|
pure virtual |
Get the scale value.
|
pure virtual |
Get the shift value.
|
pure virtual |
Set the scale mode.
|
pure virtual |
Set the power value.
|
pure virtual |
Set the scale value.
|
pure virtual |
Set the shift value.


STATIC ANALYSIS BASICS
Mount live Sysinternats toots drive:
\\live.sysinternals.com\tools
Signature check of dlt, exe files:
Ref. http://technet.microsoft.com/enus/sysinternals/bb897441.aspx
C:\> sigcheck.exe -u -e (:\<DIRECTORY>
Send to VirusTotat:
C:\> sigcheck.exe -vt <SUSPICIOUS FILE NAME>
Windows PE Analysis:
View Hex and ASCI of PE{exe or any file), with optional -n first 500 bytes:
# hexdump -C -n 500 <SUSPICIOUS FILE NAME>
# od -x somefile.exe
# xxd somefile.exe
In Windows using debug toot {works for .java files too):
C:\> debug <SUSPICIOUS FILE NAME>
-d (just type d and get a page at a time of hex)
-q (quit debugger)
Windows PE analysis:
PE Fite Compile Date/Time pert script below (Windows
PE only script).
Ref. https://www.perl.org/get.html
Ref. http://www.perlmonks.org/bare/?node_id=484287
C:\> perl.exe <SCRIPT NAME>.pl <SUSPICIOUS FILENAME>
#! perl -slw
use strict;
open EXE, '<:raw', $ARGV[0] or die "$ARGV[0]
my $dos = do{ local$/ = \65536; <EXE>};
$1" •
. ,
die "$ARGV[0] is not a .exe or .dll (sig='${ \substr
$dos, 0, 2 } ')" unless substr( $dos, 0, 2 ) eq 'MZ';
my $coffoff = 8+ unpack 'x60 V', $dos;
read( EXE, $dos, $coffoff - 65536 + 4, 65536 ) or
die$! if $coffoff > 65536;
my $ts = unpack "x$coffoff V", $dos;
print "$ARGV [0] : ", defined $ts
? ( scalar( localtime $ts) 11 "has unfathomable
timestamp value $ts" )
: 'has no timestamp';
_END_
View strings within PE and optional string length -n option:
Using stings in Linux:
strings -n 10 <SUSPICIOUS FILE NAME>
Ref. https://technet.microsoft.com/enus/sysinternals/strings.aspx
Using strings in Windows:
C:\> strings <SUSPICIOUS FILE NAME>
Find Malware in memory dump using Volatility and Windows7SPFix64 profile:
![Ref](https://github.com/volatilityfoundation/volatility]
python vol.py -f <MEMORY DUMP FILE NAME>.raw -profile=Win7SPFix64 malfind -D /<OUTPUT DUMPDIRECTORY>
Find Malware with PID in memory dump usingVolatility:
python vol.py -f <MEMORY DUMP FILE NAME>.raw -profile=Win7SPFix64 malfind -p <PID #> -D /<OUTPUTDUMP DIRECTORY>
Find suspicious processes using Volatility:
python vol.py -f <MEMORY DUMP FILE NAME>.raw -profile=Win7SPFix64 pslist
python vol.py -f <MEMORY DUMP FILE NAME>,raw -profile=Win7SPFix64 pstree
Find suspicious dlls using Volatility:
python vol.py -f <MEMORY DUMP FILE NAME>.raw -profile=Win7SPFix64 dlllist
python vol.py -f <MEMORY DUMP FILE NAME>.raw -profile=Win7SPFix64 dlldump -D /<OUTPUT DUMPDIRECTORY>
Ref. https://github.com/Defense-Cyber-CrimeCenter/DC3-MWCP
# setup.py install
Use dc3-mwcp tool to parse suspicious file:
# mwcp-tool.py -p <SUSPICIOUS FILE NAME>
PROCESS EXPLORER
Step 1: Look at running processes by running Process Explorer (GUI) and identify potential indicators of compromise:
* Items with no icon
* Items with no description or company name
* Unsigned Microsoft images (First add Verified
Signer column under View tab->Select Columns,
then go to Options tab and choose Verify Image Signatures)
* Check all running process hashes in Virus Total (Go to Options tab and select Check VirusTota l. com)
* Suspicious files are in Windows directories or user profile
* Purple items that are packed or compressed
* Items with open TCP/IP endpoints
Step 2: Signature File Check:
( See Sigcheck)
Step 3: Strings Check:
• Right click on suspicious process in Process
Explorer and on pop up window choose Strings tab
and review for suspicious URLs. Repeat for Image
and Memory radio buttons.
• Look for strange URLs in strings
Step 4: DLL View:
• Pop open with Ct rl+D
• Look for suspicious DLLs or services
• Look for no description or no company name
• Look at VirusTotal Results column
Step 5: Stop and Remove Malware:
• Right click and select Suspend for any identified suspicious processes
• Right click and select Terminate Previous Suspended processes
Step 6: Clean up where malicious files Auto start on reboot.
• Launch Autoruns
• Under Options, Check the boxes Verify Code
Signatures and Hide Microsoft entries
• Look for suspicious process file from earlier
steps on the everything tab and uncheck. Safer to
uncheck than delete, in case of error.
• Press FS, to refresh Autoruns, and confirm
malicious file has not recreated the malicious
entry into the previous unchecked auto start
location.
Step 7: Process Monitor
• If malicious activity is still persistent, run
Process Monitor.
• Look for newly started process that start soon
after terminated from previous steps.
FILE HASH ANALYSIS
HASH QUERY
VirusTotal online API query:
![Ref](https://www.virustotal.com/en/documentation/publicapi/)
(Prerequisite: Need a VT API Key)
Send a suspicious hash to VirtusTotal using cURL:
curl -v --request POST --url https://www.virustotal.com/vtapi/v2/file/report' -d apikey=<VT API KEY> -d 'resource=<SUSPICIOUS FILEHASH>'
Send a suspicious file to VirusTotal using cURL:
# curl -v -F 'file=/<PATH TO FILE>/<SUSPICIOUS FILENAME>' -F apikey=<VT API KEY> https://www.virustotal.com/vtapi/v2/file/scan
Team Cymru API:
Ref. https://hash.cymru.com, http://totalhash.com
Team Cymru malware hash lookup using whois: (Note:
Output is timestamp of last seen and detection rate)
# whois -h hash,cymru.com <SUSPICIOUS FILE HASH>
HARD DRIVE AND MEMORY ACQUISITION
WINDOWS
Create memory dump remotely:
Ref. http://kromer.pl/malware-analysis/memoryforensics-using-volatility-toolkit-to-extractmalware-samples-from-memory-dump/
Ref. http://sourceforge.net/projects/mdd/
Ref. https://technet.microsoft.com/enus/sysinternals/psexec.aspx
C: \> psexec. exe \\<HOST NAME OR IP ADDRESS> -u <DOMAIN>\<PRIVILEGED ACCOUNT> -p <PASSWORD> -cmdd_l,3.exe --o C:\memory.dmp
Ref.https://github.com/volatilityfoundation/volatility
C:\> volatility dlldump -f memory.dmp -0 dumps/
C:\> volatility procmemdump -f memory.dmp -0 dumps/
Create hard drive image using dc3dd of C:\:
Ref.https://sourceforge.net/projects/dc3dd/files/dc3dd/7.2%20-%20Windows/
C:\> dc3dd,exe if=\\,\c: of=d:\<ATTACHED OR TARGETDRIVE>\<IMAGE NAME>,dd hash=md5 log=d:\<MOUNTEDLOCATION>\<LOG NAME>, log
LINUX
Create memory dump:
dd if=/dev/fmem of=/tmp/<MEMORY FILE NAME>.dd
Create memory dump using LiME:
Ref. https://github.com/504ensicslabs/lime
wgethttps://github.com/504ensicslabs/LiME/archive/master.zip
unzip master.zip
cd LiME-master/src
make
p lime-*,ko /media/=/media/ExternalUSBDriveName/
insmod lime-3.13.0-79-generic.ko
"path=/media/Exte rna lUSBDriveName/<MEMORY DUMP>, limeformat=raw"
Make copy of suspicious process using process ID:
cp /proc/<SUSPICIOUS PROCESS ID>/exe /<NEW SAVEDLOCATION>
Grab memory core dump of suspicious process:
gcore <PIO>
Strings on gcore file:
# strings gcore.*
Create a hard drive/partition copy with tog and hash options:
dd if=<INPUT DEVICE> of=<IMAGE FILE NAME>
dc3dd if=/dev/<TARGET DRIVE EXAMPLE SDA OR SDAl> of=/dev/<MOUNTED LOCATION>\<FILE NAME>.img hash=md5 log=/<MOUNTED LOCATION>/<LOG NAME>.log
Create a remote hard drive/partition over SSH:
dd if=/dev/<INPUT DEVICE> I ssh <USERNAME>@<DESTINATION IP ADDRESS> "dd of=<DESTINATIONPATH>"
Send hard drive image zipped over netcat:
Sending host:
bzip2 -c /dev/<INPUT DEVICE> I nc <DESTINATION IPADDRESS> <PICK A PORT>
Receiving host:
nc -p <PICK SAME PORT> -l lbzip2 -d I dd of=/dev/sdb
Send hard drive image over netcat:
Sending host:
dd if=/dev/<INPUT DEVICE> bs=16M I nc <PORT>
Receiving host with Pipe Viewer meter:
nc -p <SAME PORT> -l -vv I pv -r I dd of=/dev/<INPUT DEVICE> bs=16M


Before Change
(IMAGE2_NAME,IMAGE1_NAME))])
return True
self.assertTrue(meas("Image"))
self.assertFalse(meas(OBJECTS_NAME))
module.images_or_objects.value = M.M_OBJECTS
self.assertFalse(meas("Image"))
self.assertTrue(meas(OBJECTS_NAME))
module.images_or_objects.value = M.M_IMAGES_AND_OBJECTS
After Change
def test_02_03_get_measurement_images(self):
"""Test the get_measurment_images function for some different cases"""
for iocase, names in (
(M.M_IMAGES, [cpmeas.IMAGE]),
(M.M_OBJECTS, [OBJECTS_NAME]),
(M.M_IMAGES_AND_OBJECTS, [cpmeas.IMAGE, OBJECTS_NAME])):
module = M.MeasureCorrelation()
module.image_groups[0].image_name.value = IMAGE1_NAME
module.image_groups[1].image_name.value = IMAGE2_NAME
module.object_groups[0].object_name.value = OBJECTS_NAME
module.images_or_objects.value = iocase
for name, mfs in ((cpmeas.IMAGE, self.all_image_measurement_formats),
(OBJECTS_NAME, self.all_object_measurement_formats)):
if name not in names:
continue
for mf in mfs:
ftr = mf.split("_")[1]
ans = module.get_measurement_images(
None, name, "Correlation", ftr)
expected = ["%s_%s" % (i1, i2) for i1, i2 in
((IMAGE1_NAME, IMAGE2_NAME),
(IMAGE2_NAME, IMAGE1_NAME))]
if mf in self.asymmetrical_measurement_formats:
self.assertTrue(all([e in ans for e in expected]))
else:
self.assertTrue(any([e in ans for e in expected]))
def test_02_04_01_get_measurement_columns_images(self):
module = M.MeasureCorrelation()
module.image_groups[0].image_name.value = IMAGE1_NAME
module.image_groups[1].image_name.value = IMAGE2_NAME


13 February 2006
The Ministry of Health in China has reported the country’s 12th laboratory confirmed case of human infection with the H5N1 avian influenza virus.
The case occurred in a 20-year-old female farmer from the south-central province of Hunan. She developed symptoms on 27 January and was subsequently hospitalized with severe pneumonia. Symptom onset followed the culling of poultry raised by her household. She died on 4 February.
To date, China has reported 12 laboratory-confirmed cases. Of these, eight have been fatal.


| # | Sensor |
|---|---|
| 0 | Drive Subsystem Front Left Encoder |
| 1 | Drive Subsystem Front Left Encoder |
| 2 | Drive Subsystem Front Right Encoder |
| 3 | Drive Subsystem Front Right Encoder |
| 4 | Drive Subsystem Rear Left Encoder |
| 5 | Drive Subsystem Rear Left Encoder |
| 6 | Drive Subsystem Rear Right Encoder |
| 7 | Drive Subsystem Rear Right Encoder |
| 23 | Tote Lifter Subsystem Right Limit Switch |
| 24 | Tote Lifter Subsystem Left Limit Switch |
| 25 | Container Hook Subsystem Upper Limit Switch |
| # | Motor |
|---|---|
| 0 | Drive Subsystem Front Left Jaguar |
| 1 | Drive Subsystem Front Right Jaguar |
| 2 | Drive Subsystem Rear Left Jaguar |
| 3 | Drive Subsystem Rear Right Jaguar |
| 4 | Container Hook Subsystem Talon |
| 5 | Tote Lifter Subsystem Ejector Talon |
| # | Solenoid |
|---|---|
| 0 | Tote Lifter Subsystem Raise Solenoid Output |
| 1 | Tote Lifter Subsystem Storage Solenoid Forward |
| 2 | Tote Lifter Subsystem Storage Solenoid Reverse |
| 3 | Tote Lifter Subsystem Lower Vent Solenoid Output |
| 4 | Tote Lifter Subsystem Gate Solenoid Output |


File: lib/draft-js/keyCommandUndo.js
/** * Copyright (c) 2013-present, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule keyCommandUndo * */ 'use strict'; var EditorState = require('./EditorState'); function keyCommandUndo(e, editorState, updateFn) { var undoneState = EditorState.undo(editorState); // If the last change to occur was a spellcheck change, allow the undo // event to fall through to the browser. This allows the browser to record // the unwanted change, which should soon lead it to learn not to suggest // the correction again. if (editorState.getLastChangeType() === 'spellcheck-change') { var nativelyRenderedContent = undoneState.getCurrentContent(); updateFn(EditorState.set(undoneState, { nativelyRenderedContent: nativelyRenderedContent })); return; } // Otheriwse, manage the undo behavior manually. e.preventDefault(); if (!editorState.getNativelyRenderedContent()) { updateFn(undoneState); return; } // Trigger a re-render with the current content state to ensure that the // component tree has up-to-date props for comparison. updateFn(EditorState.set(editorState, { nativelyRenderedContent: null })); // Wait to ensure that the re-render has occurred before performing // the undo action. setTimeout(function () { updateFn(undoneState); }, 0); } module.exports = keyCommandUndo;


--- layout: page title : Assignments header : Assignments group: navigation --- {% include JB/setup %}
| Assignment | Topic | Due date |
|---|---|---|
| A1 | Javascript and the DOM | Friday Oct 14, 10 p.m. |
| A2 | REST | Friday, Nov 4, 10 p.m. |
| Project | Proposal | Friday, Nov 11, 10 p.m. |
| Project | Final Product | Friday, Dec 2, 10 p.m. |
You will be using GitHub repositories to manage your assignments. Your life will be considerably easier if you read and follow the instructions for working on and submitting your assignment.
You will want to spend some time learning how to use Git and GitHub if you are not already familiar wtih it. The GitHub Guides are a pretty good place to start.
You will need a GitHub id. This means that you should be thinking about privacy issues. The repositories that you will use for the course are private in the sense that only you, your team mates (for the project), the TAs, and I will be able to see the repo on GitHub. For many people there is really nothing to worry about in using the same GitHub id for the course and for other work that you do, especially since GitHub has a pretty strong privacy policy.
However, you might have a reason not to associate your personal GitHub use with the course, or vice versa, and in that case you may want to create a GitHub id for school use. You will need to use a valid email address, and I will need a way to identify who you are, so if you don't trust GitHub to protect your email address, then we will have to talk.


This page is served by Quarkus.
Thanks also to gRPC (gilded Remote Procedure Call).
Visit the Dev UIThis page: src/main/resources/META-INF/resources/index.html
App configuration: src/main/resources/application.properties
Static assets: src/main/resources/META-INF/resources/
Code: src/main/java
Starter code:
@Path: /outcome
Practical step-by-step guides to help you achieve a specific goal. Use them to help get your work done.
Everyone has a favorite IDE they like to use to code. Learn how to configure yours to maximize your Quarkus productivity.


Nowadays, food establishments such as restaurants have become part of our daily lives. Chicago is a great example of a big city which gathers a huge variety of such establishments. As such, we focus our project on facilities located there.
In this project, we firstly try to understand which factors are most at stake when talking about food safety in food establishments in Chicago. In the process, we also take a detour and use socio-economic indicators of Chicago community areas in order to see if eating safely is equally accessible to all members of society. To this end, we will see whether our dataset supports the existence of food deserts in Chicago.
Our ultimate aim is to promote public health by computing a Safety Score based on information from inspections as well as other metrics that prove useful during analysis. The Chicago residents can use this score to safely decide where to eat out.
Our starting point is the Chicago Food Inspection data set, which contains information about the inspections of food establishments in Chicago from January 1, 2010 up to the present. As we will see further down, each inspection is accompanied by information about the inspected facility such as its location and its type (restaurant, medical establishment, school...). The inspection outcome depends on whether the establishment was found to have any of the 45 possible violations, and in this research we consider the following results:
In this part of our research, we got familiar with how inspection outcomes differ according to various establishment and inspection features. We also examined and analyzed the performance evolution of facilities in Chicago.
Does the type of an establishment influence its inspection outcome?
Some insights:
Food cleanliness is a top priority in the medical world and there is no room for error. Medical establishments can not get passes with conditions: they either pass or fail the inspections. This strict approach might explain why they have the highest proportion of fails.
Are reinspections always a success?
Reinspections correspond to inspections that establishments get for a second time, typically after a fail.
Some insights:
The proportion of facilities which get a pass in their reinspection is bigger than that which get a pass at their first inspection. This makes sense as establishments take into consideration the comments given by the inspectors before their reinspections.
We can also see that the proportion of passes with conditions is smaller for the reinspections. This makes sense as giving such a result would mean giving establishments "a third chance".
Each establishment is classified into one of three risk categories according to its likelihood of affecting the public’s health. Category 1 being the highest in terms of risk and 3 the lowest. The inspection frequency is tied to this risk.
Some insights:
Surprisingly, the riskiest establishments seem to get the least fails. This might be due to their awareness of the matter and hence their care in maintaining their sanitation.
Establishments with the highest risk also get the highest proportion of passes with conditions. This could mean that inspectors might be less severe with them given that it is very challenging to maintain such a risky establishment.
The proportion of passes seems independent of the risk of the facility.
There are several stereotypes about certain cuisines being riskier than others. However, the food inspection results might surprise you...
Does pricier imply safer?
Some insights:
We would expect the cheapest restaurants to have the highest fail proportion. But this is not the case: the price range actually does not influence inspection outcomes.
Ratings given by the community certainly reflect the establishments quality, but they do not always reflect the inspection outcomes. For instance, establishments with a 4.5 rating have more failed inspections than establishments with a 4.0 rating.
We often expect to find diverse and numerous food places in big cities. However, we found that in some areas of Chicago, residents are lacking access to healthy and affordable food options due to the absence of grocery stores within convenient travelling distance. This phenomenon is referred to as a food desert, a.k.a. food apartheid. Further, in a report by the Illinois Advisory Committee to the United States Commission on Civil Rights, it is stated that these food desert neighborhoods are almost exclusively in African American neighborhoods making the issue a civil rights one beyond its public health dimension.
Let's take a look at establishments that represent healthy food providers (grocery stores, farmer's markets, fish markets, meat markets...). We retrieve these establishments from the inspection dataset1 and plot their density by surface for Chicago's community areas.
We certainly see a difference in the concentration of grocery stores between the North and the South, the south being quite sparse.
“Chicago’s segregation is certainly legendary, with the North and South sides divided by class and race. To keep it stereotypically simple: The North Side is white, the South Side is black.”
- Ashok Selvam, Senior Editor Eater Chicago
Chicago is the perfect example of a melting pot, with almost even proportions of African American, White and Latino people and a minority of Asians. However, the map below shows us that there is a clear separation between the North and the South, the South having mostly African American neighborhoods, the North mostly White neighborhoods and the West Latino neighborhoods.
As we can see below, the grocery stores' density is positively correlated with Population Count by community area as well as with Per Capita Income. It is on the other hand negatively correlated with Below Poverty Level. These observations make sense if we think about grocery stores wanting to maximize their profit.
"Grocery stores typically have only 1-2% profit margins, so the difficulties involved in running an urban supermarket are often seen as too costly in an already-risky business."
A solution that the Illinois State could put into practice is the one implemented in the state of New York: "providing zoning and financial incentives to grocery stores in underserved communities".
We compiled a technical score for several food establishments in Chicago. This score heavily depends on the violations committed at the time of inspection (e.g. whether they were critical or not).
Critical violations include improper personal hygiene or rodent and/or insect infestation. Serious and moderate violations include no proper protection from contamination or poorly constructed walls. The score takes into account the severity of critical violations and hence gives bigger weights to the attributes linked to them. It also takes into account whether there were cases of food poisoning caused by the establishment, or if there were any "hidden allergens" in the establishment. The pie chart below showcases the different weights given to the parameters we use to compute our score.
The final score takes into account the opinion of the Yelp community by using the average user establishment rating. The map below showcases the final score. Simply use the slider to select the importance attributed to the user rating.
For example, selecting 0% will result in a total score that is equal to the technical score, whereas selecting 100% will result in a total score that is the user rating.
Our final score follows this simple formula.
This research has allowed us to uncover many insights into food establishments in Chicago.
Firstly, we found the features which affect food establishment inspection outcomes the most, a result which could be arguably generalized to many other cities. This has also enabled us to argue against stereotypes in some cases such as stereotypically "less clean" cuisines.
Next, we took a look at the interesting phenomenon of food deserts. We have indeed found that our data set supports the claim that such deserts do exist in Chicago. We hope that in the future, initiatives such as the NYC one will be implemented in Chicago.
Finally, we computed a safety scores for food establishments and displayed them on a map which could be used by users to be able to eat safely in Chicago.