What are they doing to our queen? Asks Mbalula after Miss SA reveals Miss Universe outfit
Social media critics including the minister of transport were unimpressed with the national costume, inspired by the SA flag.
by Citizen reporterMiss South Africa Zozibini Tunzi in her outfit for Miss Universe 2019. Picture: Instagram.
At an event on Friday, Miss South Africa Zozibini Tunzi unveiled her South African flag-inspired national costume for the Miss Universe pageant, which will take place on December 8 in Atlanta, USA.
On social media, some have responded negatively to the outfit, with Minister of Transport Fikile Mbalula among those who are unimpressed.
“What are they doing to our queen?” he asked on Twitter, adding: “No man”.
Tunzi managed to work her commitment to the cause of stamping out gender-based violence and the #HeForShe campaign into the outfit.
She asked South African men to write love letters to the women of South Africa, which were incorporated into the bodysuit in the colourful ribbons that surround it.
Lloyd Kandlin designed the outfit.
At the same event at the Maslow Hotel in Sandton on Friday, Tunzi also unveiled her evening gown for the pageant, designed by Biji La Maison. It appears to have been met with more approval than the national costume by the Twitter critics.
Tunzi’s parents and siblings were present at the costume unveiling.
At the event, it was also revealed that instead of a national gift, Miss Universe contestants will each bring a soft toy to be donated to charity.
Tunzi’s doll is designed by former Miss South Africa Bokang Montjane, from her range of dark-skinned dolls with natural hair, made to inspire confidence in young people of colour.


hosted by: {{ event.createdBy.hosterName || event.createdBy.username}}
DATE: {{ event.formattedDate}}
TIME: {{ event.formattedTime}}
{{ event.duration}}
{{ event.description}}
The expected weather is: {{ weatherSummary.summary }}
Powered by Dark Sky{{ event.guests[0].username }}, {{event.guests[1].username}} & {{ event.guests.length - 2}} other guests are going
One person has signed up so far
All places are available, grab a seat!
There are {{ event.placesRemaining }} places remaining
The host has no other events


A toolbox for designing and evaluating predictive models with resampling methods. The aim of this package is to provide a simple and efficient general framework for working with any type of prediction problem, be it classification, regression or survival analysis, that is easy to extend and adapt to your specific setting. Some commonly used methods for classification, regression and survival analysis are included.
| Version: | 2.2.10 |
| Depends: | R (≥ 3.0.2) |
| Imports: | data.table, dplyr, ggplot2 (≥ 2.0.0), graphics, grDevices, lazyeval, magrittr, methods, stats, tidyr, utils |
| LinkingTo: | Rcpp (≥ 0.12.1) |
| Suggests: | caret, cmprsk, e1071, glmnet, Hmisc, MASS, parallel, party, pamr, randomForest, RColorBrewer, rpart, survival (≥ 2.42-5), testthat (≥ 0.9.1) |
| Published: | 2018-07-30 |
| Author: | Christofer Backlin [aut, cre], Mats Gustafsson [aut] |
| Maintainer: | Christofer Backlin <emil at christofer.backlin.se> |
| BugReports: | https://github.com/Molmed/emil/issues |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | https://github.com/Molmed/emil |
| NeedsCompilation: | yes |
| Citation: | emil citation info |
| CRAN checks: | emil results |
| Reference manual: | emil.pdf |
| Package source: | emil_2.2.10.tar.gz |
| Windows binaries: | r-devel: emil_2.2.10.zip, r-release: emil_2.2.10.zip, r-oldrel: emil_2.2.10.zip |
| OS X binaries: | r-release: emil_2.2.10.tgz, r-oldrel: emil_2.2.10.tgz |
| Old sources: | emil archive |
Please use the canonical form https://CRAN.R-project.org/package=emil to link to this page.


Police searching for 'hugging thief' in Brooklyn
by Eyewitness NewsPARK SLOPE, Brooklyn (WABC) -- Police are searching for a hugging thief in Brooklyn.
They say a man approached a 78-year-old woman in Park Slope in early November and robbed her by embracing her.
He claimed to know her after the hug, then left the area.
Hours later, the victim realized her wallet was missing when she tried to go to the bank.


Serving all of central Pennsylvania
A Trusted Supply Service
White Rose Tattoo Supply is a delivery service that provides tattoo shops and tattoo artists the equipment they need to preform their jobs. When you partner with us, we become an extension of your team and we are there to provide whatever you need to preform your job. Contact us if you have any questions or to request a route in your area, and a rep will return your message as soon as possible.


|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use net.sf.morph.transform | |
|---|---|
| net.sf.morph | Core classes for use by other parts of the Morph framework. |
| net.sf.morph.context.contexts | Context implementations. |
| net.sf.morph.integration.commons.beanutils | Integration with Apache Commons Beanutils. |
| net.sf.morph.integration.commons.collections | Integration with Apache Commons Collections. |
| net.sf.morph.lang | Defines basic Languages used to retrieve and set information in bean-like objects. |
| net.sf.morph.lang.languages | Language implementations. |
| net.sf.morph.transform | Defines a standard way to transform information from one format or source to another. |
| net.sf.morph.transform.converters | Converter implementations. |
| net.sf.morph.transform.copiers | Copier implementations. |
| net.sf.morph.transform.transformers | Transformer implementations. |
| net.sf.morph.util | Utility classes used to implement the Morph framework. |
| Classes in net.sf.morph.transform used by net.sf.morph | |
|---|---|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedCopier
An extension of the Copier interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| TransformationException
|
| Classes in net.sf.morph.transform used by net.sf.morph.context.contexts | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
| Classes in net.sf.morph.transform used by net.sf.morph.integration.commons.beanutils | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| TransformationException
|
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.integration.commons.collections | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.lang | |
|---|---|
| TransformationException
|
| Classes in net.sf.morph.transform used by net.sf.morph.lang.languages | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| TransformationException
|
| Classes in net.sf.morph.transform used by net.sf.morph.transform | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| Copier
An object that can copy information from a source object to a destination object. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| TransformationException
|
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.transform.converters | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| Copier
An object that can copy information from a source object to a destination object. |
|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedCopier
An extension of the Copier interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| ImpreciseTransformer
Defines a transformer whose operation may result in a loss of data precision. |
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.transform.copiers | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| Copier
An object that can copy information from a source object to a destination object. |
|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedCopier
An extension of the Copier interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| NodeCopier
A copier used by a net.sf.morph.transform.GraphTransformer to
assist in the transformation of one object graph into another object graph. |
|
| TransformationException
|
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.transform.transformers | |
|---|---|
| Converter
An object that can convert one type of object into another type of object. |
|
| Copier
An object that can copy information from a source object to a destination object. |
|
| DecoratedConverter
An extension of the Converter interface that defines a few more convenient methods. |
|
| DecoratedCopier
An extension of the Copier interface that defines a few more convenient methods. |
|
| DecoratedTransformer
An extension of the Transformer interface that defines extra methods. |
|
| ExplicitTransformer
A Transformer that explicitly states which of its source
classes are transformable to which destination classes. |
|
| ImpreciseTransformer
Defines a transformer whose operation may result in a loss of data precision. |
|
| TransformationException
|
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
| Classes in net.sf.morph.transform used by net.sf.morph.util | |
|---|---|
| TransformationException
|
|
| Transformer
Transforms information taken from a source and makes it available at a destination. |
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |


Hi im LUNA I enjoy making python projects, I also know html and css. I want to learn c++ and c# so I can make better programs.
Check some out bye clicking the button at the top.
Come join my discord (click the button at the top) if you need help or just wanna chat or check out my other social media.
Some music i like.


0219 ALTA VERDE SUBD., KM6, ASIN RD, TADIANGAN, TUBA, BENGUET
Contact #:09152856847|E-Mail<EMAIL_ADDRESS>| Educational background | School Year |
|---|---|
| Home School | ---- |
| ALS Baguio Central Elementary School | 2014-2015 |
Weight: 104lbs
Height: 5'7"
Hobbies: Reading, Writing, playing games.


Definition for loading an existing plasmid
| Field | Type | Label | Description |
| data | ExistingPlasmid.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Existing plasmid ID |
|
| attributes | ExistingPlasmidAttributes |
|
Defines attributes for loading an existing plasmid
| Field | Type | Label | Description |
| created_at | google.protobuf.Timestamp | Timestamp for creation |
|
| updated_at | google.protobuf.Timestamp | Timestamp for update |
|
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| depositor | string | Depositor of the stock |
|
| publications | string | repeated | List of related publications |
| image_map | string | Image map for the plasmid |
|
| sequence | string | Sequence for the plasmid |
|
| name | string | Unambiguous name for the plasmid |
| Field | Validations |
| created_at |
|
| updated_at |
|
| created_by |
|
| name |
|
Definition for loading an existing strain
| Field | Type | Label | Description |
| data | ExistingStrain.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Existing strain ID |
|
| attributes | ExistingStrainAttributes |
|
Defines attributes for loading an existing strain
| Field | Type | Label | Description |
| created_at | google.protobuf.Timestamp | Timestamp for creation |
|
| updated_at | google.protobuf.Timestamp | Timestamp for update |
|
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| depositor | string | Depositor of the stock |
|
| publications | string | repeated | List of related publications |
| label | string | Descriptor for the strain, a quick overview of its key genetic modifications |
|
| species | string | Species of the strain |
|
| plasmid | string | Related plasmid for the strain |
|
| parent | string | Parent of the strain |
|
| names | string | repeated | List of names for the strain |
| Field | Validations |
| created_at |
|
| updated_at |
|
| created_by |
|
| updated_by |
|
| label |
|
| species |
|
Metadata definition for traversing the collection
| Field | Type | Label | Description |
| next_cursor | int64 | A unique pointer to the next set of result in the collection. Set the cursor value parameter to the value of next_cursor to retrieve the next set of collection using the same method |
|
| limit | int64 | Maximum number of records that can be fetch per request |
|
| total | int64 | Total number of records in the collection. |
Definition for creating a new plasmid
| Field | Type | Label | Description |
| data | NewPlasmid.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| attributes | NewPlasmidAttributes |
|
Defines attributes for creating a new plasmid
| Field | Type | Label | Description |
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| depositor | string | Depositor of the stock |
|
| publications | string | repeated | List of related publications |
| image_map | string | Image map for the plasmid |
|
| sequence | string | Sequence for the plasmid |
|
| name | string | Unambiguous name for the plasmid |
| Field | Validations |
| created_by |
|
| updated_by |
|
| depositor |
|
| name |
|
Definition for creating a new strain
| Field | Type | Label | Description |
| data | NewStrain.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| attributes | NewStrainAttributes |
|
Defines attributes for creating a new strain
| Field | Type | Label | Description |
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| depositor | string | Depositor of the stock |
|
| publications | string | repeated | List of related publications |
| label | string | Descriptor for the strain, a quick overview of its key genetic modifications |
|
| species | string | Species of the strain |
|
| plasmid | string | Related plasmid for the strain |
|
| parent | string | Parent of the strain |
|
| names | string | repeated | List of names for the strain |
| Field | Validations |
| created_by |
|
| updated_by |
|
| depositor |
|
| label |
|
| species |
|
Definition of an individual plasmid
| Field | Type | Label | Description |
| data | Plasmid.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique identifier for the plasmid |
|
| attributes | PlasmidAttributes |
|
Definition of various stock attributes
| Field | Type | Label | Description |
| created_at | google.protobuf.Timestamp | Timestamp for creation |
|
| updated_at | google.protobuf.Timestamp | Timestamp for update |
|
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| depositor | string | Depositor of the stock |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| publications | string | repeated | List of related publications |
| image_map | string | Image map for the plasmid |
|
| sequence | string | Sequence for the plasmid |
|
| name | string | Unambiguous name for the plasmid |
| Field | Validations |
| created_at |
|
| updated_at |
|
| created_by |
|
| updated_by |
|
| name |
|
List of plasmids
| Field | Type | Label | Description |
| data | PlasmidCollection.Data | repeated |
|
| meta | Meta |
|
| Field | Validations |
| meta |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique identifier for the stock |
|
| attributes | PlasmidAttributes |
|
Definition for creating a new plasmid
| Field | Type | Label | Description |
| data | PlasmidUpdate.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique ID for plasmid |
|
| attributes | PlasmidUpdateAttributes |
|
| Field | Validations |
| id |
|
Defines attributes for updating a plasmid
| Field | Type | Label | Description |
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| depositor | string | Depositor of the stock |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| publications | string | repeated | List of related publications |
| image_map | string | Image map for the plasmid |
|
| sequence | string | Sequence for the plasmid |
|
| name | string | Unambiguous name for the plasmid |
| Field | Validations |
| updated_by |
|
| Field | Type | Label | Description |
| id | string | Unique identifier for the stock |
| Field | Validations |
| id |
|
StockParameters defines fields for manipulating output of Stock collection
| Field | Type | Label | Description |
| cursor | int64 | A unique pointer to the next set of result in the list (default is 0) |
|
| limit | int64 | Maximum number of records that can be fetch per request (default is 10) |
|
| filter | string | The `filter` field restricts the data return by the collection. To use it, supply one or multiple allowed fields to filter followed by a filter expression. It uses the following syntax... field_name operator expression The following fields of `StockAttributes` definition are allowed to be used for filtering * depositor - Depositor of the stock (string) * parent - Parental strain (string) (currently not implemented) * plasmid - Related plasmid for the strain (string) * species - The species of the strain (string) * summary - Summary of the stock (string) * name - Name used for strain (string), searches in the "names" attribute * plasmid_name - Name used for plasmid (string) * created_at - Date the stock was created (number), can be in the following formats: YYYY-MM-DD, YYYY-MM, YYYY * updated_at - Date the stock was updated (number), can be in the following formats: YYYY-MM-DD, YYYY-MM, YYYY field_name - Any one of the allowed field_name of the `StockAttributes` definition. operator - Defines the type of filter match to use. It could be any of the following four and all of them should be URL-encoded for http request. Operators for strings =~ Contains substring !~ Not contains substring === Equals != Not equals Operators for number == Equals > Greater than < Less than <= Less than equal to >= Greater than equal to Operators for dates $== Equals $> Greater than $< Less than $<= Less than equal to $>= Greater than equal to Operators for items in arrays @=~ Contains substring @!~ Not contains substring (not implemented yet) @== Equals @!= Not equals expression - The value that will be included or excluded from the result. URL-reserved characters must be URL-encoded for http request. filter: "created_at$>=2018-12-01" filter: "depositor===Costanza" Filter can be combined using OR or AND boolean logic. * The OR is represented using a comma(,). * The AND is represented using a semi-colon(;). * AND and OR operators can be combined and AND takes precedence over OR. filter: "depositor===Benes;created_at$>=2018-12-01" The sort field allow to sort the data return by the collection based on fields of `StockAttributes. To use it, supply a comma separated one or more allowed field from the definition of `StockAttributes`. |
Definition of an individual strain
| Field | Type | Label | Description |
| data | Strain.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique identifier for the strain |
|
| attributes | StrainAttributes |
|
Definition of various strain attributes
| Field | Type | Label | Description |
| created_at | google.protobuf.Timestamp | Timestamp for creation |
|
| updated_at | google.protobuf.Timestamp | Timestamp for update |
|
| created_by | string | User who created stock entry |
|
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| depositor | string | Depositor of the stock |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| publications | string | repeated | List of related publications |
| label | string | Descriptor for the strain, a quick overview of its key genetic modifications |
|
| species | string | Species of the strain |
|
| plasmid | string | Related plasmid for the strain |
|
| parent | string | Parent of the strain |
|
| names | string | repeated | List of names for the strain |
| Field | Validations |
| created_at |
|
| updated_at |
|
| created_by |
|
| updated_by |
|
| label |
|
| species |
|
List of strains
| Field | Type | Label | Description |
| data | StrainCollection.Data | repeated |
|
| meta | Meta |
|
| Field | Validations |
| meta |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique identifier for the stock |
|
| attributes | StrainAttributes |
|
Definition for creating a new strain
| Field | Type | Label | Description |
| data | StrainUpdate.Data |
|
| Field | Validations |
| data |
|
| Field | Type | Label | Description |
| type | string | Resource name |
|
| id | string | Unique ID for strain |
|
| attributes | StrainUpdateAttributes |
|
| Field | Validations |
| id |
|
Defines attributes for updating a strain
| Field | Type | Label | Description |
| updated_by | string | User who updated stock entry |
|
| summary | string | Summary of the stock |
|
| editable_summary | string | Editable version of the stock summary (Slate JSON format) |
|
| depositor | string | Depositor of the stock |
|
| genes | string | repeated | List of associated genes |
| dbxrefs | string | repeated | List of database cross references |
| publications | string | repeated | List of related publications |
| label | string | Descriptor for the strain, a quick overview of its key genetic modifications |
|
| species | string | Species of the strain |
|
| plasmid | string | Related plasmid for the strain |
|
| parent | string | Parent of the strain |
|
| names | string | repeated | List of names for the strain |
| Field | Validations |
| updated_by |
|
The stock service specification
| Method Name | Request Type | Response Type | Description |
| GetStrain | StockId | Strain | Retrieves strain by ID |
| GetPlasmid | StockId | Plasmid | Retrieves stock by ID |
| CreateStrain | NewStrain | Strain | Create a new strain |
| CreatePlasmid | NewPlasmid | Plasmid | Create a new plasmid |
| UpdateStrain | StrainUpdate | Strain | Update an existing strain |
| UpdatePlasmid | PlasmidUpdate | Plasmid | Update an existing plasmid |
| RemoveStock | StockId | .google.protobuf.Empty | Remove an existing stock |
| ListStrains | StockParameters | StrainCollection | List strains using pagination, ten entries are retrieved by default |
| ListPlasmids | StockParameters | PlasmidCollection | List plasmids using pagination, ten entries are retrieved by default |
| LoadStrain | ExistingStrain | Strain | Load existing strain |
| LoadPlasmid | ExistingPlasmid | Plasmid | Load existing plasmid |
| .proto Type | Notes | C++ Type | Java Type | Python Type |
| double | double | double | float | |
| float | float | float | float | |
| int32 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead. | int32 | int | int |
| int64 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead. | int64 | long | int/long |
| uint32 | Uses variable-length encoding. | uint32 | int | int/long |
| uint64 | Uses variable-length encoding. | uint64 | long | int/long |
| sint32 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s. | int32 | int | int |
| sint64 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int64s. | int64 | long | int/long |
| fixed32 | Always four bytes. More efficient than uint32 if values are often greater than 2^28. | uint32 | int | int |
| fixed64 | Always eight bytes. More efficient than uint64 if values are often greater than 2^56. | uint64 | long | int/long |
| sfixed32 | Always four bytes. | int32 | int | int |
| sfixed64 | Always eight bytes. | int64 | long | int/long |
| bool | bool | boolean | boolean | |
| string | A string must always contain UTF-8 encoded or 7-bit ASCII text. | string | String | str/unicode |
| bytes | May contain any arbitrary sequence of bytes. | string | ByteString | str |


Feature Style Specification
Version 0.016 - 2018-12-03
1. Overview
This document defines the way feature style information (i.e. colors, line width, symbols, etc.) should be handled at the various levels in GDAL's vector drivers (OGR).
The following GDAL vector drivers have varying levels of support for feature styles: DWG (libopencad), DWG (Teigha), DXF, KML (libkml), MapInfo, MicroStation DGN v7 and DGN v8, OpenJUMP JML and PDF.
1.1 Style is a property of Feature object
Conceptually, the feature style should be seen as a property of a feature. Even though some systems store style information in a special attribute, in GDAL it is more consistent to see the style as a property, just the same way the geometry of a feature is also a property.
This does not prevent us from storing the style information in an attribute when writing to some formats that have no provision for styles (e.g. E00). But then at the time such a dataset is opened through GDAL, the name of the attribute that contains style information should either be specified in some metadata, or be specified by the user.
Also, in the SFCOM interface, the style information will be stored in an attribute just like the geometry is.
1.2 Feature Styles can be stored at 2 levels
The style defines the way a feature should be drawn, but it is very common to have several features that share the same style. In those cases, instead of duplicating the style information on each feature, we will provide a more efficient way to share style information.
There are two levels at which style information can be found:
A dataset can have a table of pre-defined styles that can then be referred to by the layers or by the individual features. The mechanism for that is defined further down in this document.
A feature (OGRFeature object) can have its own complete style definition. Alternatively, a feature can be linked to a style in the dataset's table of styles. This can save storage space when the same styles are reused often.
It should be possible to have style information stored at one or more of the various levels while working on a given dataset. The level(s) where the style is actually stored will depend on the most efficient approach for the format we are dealing with.
1.3 Drawing Tools
We define a small set of drawing tools that are used to build style definitions:
PEN: For linear styles
BRUSH: For filling areas
SYMBOL: Point symbols
LABEL: For annotations
Each drawing tool can take a number of parameters, all optional. The style syntax is built in a way that a system that cannot support all possible parameters can safely skip and ignore the parameters it does not support. This will also make it easy to extend the specification in the future without breaking existing code or applications.
A style can use a single tool, or use a combination of one or more tools. By combining the use of several tools in a style, one can build virtually any type of graphical representation. For instance, the SYMBOL tool can be used to place spaced symbols along a line. Also, the LABEL tool can be used to place text on a point, stretch it along a line, or even, by combining the PEN tool with the LABEL tool, use the line as a leader to the text label, and draw the text string on the last vertex of the line.
Of course, few systems can support all that. But the intention here is to have a style specification that is powerful and flexible enough to allow all types of formats to exchange style information with the least possible loss.
1.4 Feature attributes can be used by style definitions
In some cases, it might be useful for a style definition to refer to an attribute field on the feature for a given tool parameter's value instead of having a hardcoded value inside the style itself.
Example of this are text angle, text string, etc... these values change for every single text label, but we can share the rest of the label style at the layer level if we lookup the angle and text string in an attribute on each feature.
The syntax of the style string provides a way that any parameter value can be either a constant value, or a lookup to an attribute field.
1.5 Tool parameter units
Several parameter values can be expressed in different measurement units depending on the file format you are dealing with. For instance, some systems express line width, or text height in points, other in pixels, and others use ground units. In order to accommodate all that, all parameters can be specified in one of the following units systems:
g: Map Ground Units (whatever the map coordinate units are)
px: Pixels
pt: Points (1/72 inch)
mm: Millimeters
cm: Centimeters
in: Inches
Some tools will have to be provided at the GDAL client level to simplify the conversion of any value from one units system to another. This would imply that the GDAL client has to specify a map scale so that conversions from ground units to paper/pixel units can be performed.
2. Feature Style String
As was mentioned earlier, styles definitions will usually be stored as strings, either in a per-layer (or per-dataset) table, or directly in the features.
2.1 Examples
Here are some example style definition strings:
A 5 pixels wide red line:
PEN(c:#FF0000,w:5px)
A polygon filled in blue, with a black outline:
BRUSH(fc:#0000FF);PEN(c:#000000)
A point symbol:
SYMBOL(c:#00FF00,id:"points.sym-45,ogr-sym-7")
A text label, taking the text string from the "text_attribute" attribute field:
LABEL(f:"Times New Roman",s:12pt,t:{text_attribute})"
Here is what a style table that contains all the above styles could look like:
road: PEN(c:#FF0000,w:5px)
lake: BRUSH(fc:#0000FF);PEN(c:#000000)
campsite: SYMBOL(c:#00FF00,id:"points.sym-45,ogr-sym-7")
label: LABEL(f:"Times New Roman",s:12pt,t:{text_attribute})
Then individual features can refer to styles from the table above using the "@" character followed by the style name in their style property.
For instance, a feature with its style set to "@road" would be drawn as a red line.
2.2 Style String Syntax
Each feature object has a style property (a string):
<style_property> = "<style_def>" | "" | "@<style_name>" | "{<field_name>}"
<style_def>
is defined later in this section.An empty style string means that the feature's style is unspecified. It does not indicate that the feature is invisible – an invisible feature may be indicated using a fully transparent color, like PEN(c:#00000000).
@<style_name>
is a reference to a predefined style in the layer or the dataset's style table. The layer's table is looked up first, and if style_name is not found there then the dataset's table will be looked up.Finally,
{<field_name>}
means that the style property should be read from the specified attribute field.
The <style_def> is the real style definition. It is a combination of 1 or more style parts separated by semicolons. Each style_part uses a drawing tool to define a portion of the complete graphical representation:
<style_def> = <style_part>[;<style_part>[;...]]
<style_part> = <tool_name>([<tool_param>[,<tool_param>[,...]]])
<tool_name> = name of a drawing tool, for now: PEN | BRUSH | SYMBOL | LABEL
<tool_param> = <param_name>:<param_value>
<param_name> = see list of parameters names for each drawing tool
<param_value> = <value> | <value><units>
<value> = "<string_value>" | <numeric_value> | {<field_name>}
<units> = g | px | pt | mm | cm | in
By default, style parts are drawn in the order that they appear in the style_def string unless each part is assigned a different level parameter value (see the level parameter definition).
All drawing tool parameters are optional. So it is legal to have a style_part with an empty drawing tool parameter list (e.g. "PEN()"). For each parameter that does not have any specified value, it is up to the client application to use its own default value. This document provides advisory default values for most parameters, but it is not mandatory for an application to use those default values.
When {<field_name>} is used for a tool_param value, several options are available with respect to the units. The units can be specified after the field name as in PEN(c:#FF0000,w:{line_width}pt) or can be left unspecified as in PEN(c:#FF0000,w:{line_width}). In the first case, the default units will be points (pt), but if the attribute field line_width contains a value followed by a units abbreviation (e.g. "5px") then the units specified in the attribute fields have precedence (in this case pixels). Note that the attribute field does not have to contain a units value and probably won't in most cases; it is just an optional feature to be able to override the default units from inside an attribute field's value.
2.3 Pen Tool Parameters
Applicable geometry types:
Point: When applied to a point, a PEN tool can only define the color and the size of the point to draw.
Polyline: This is the most obvious case.
Polygon: Defines the way the outline of a polygon should be drawn.
Here is the current list of PEN tool parameters. While this is sufficient to cover all the cases that we have encountered so far, new parameters might be added in the future to handle new types of graphical representation. Note again that all parameters are optional:
c
: Pen Color, expressed hexadecimal (#RRGGBB[AA])[AA]: the last 2 digits define the alpha channel value, with 0 being transparent and FF being opaque. The default is FF (opaque)
Suggested default: black (c:#000000)
Example: PEN(c:#FF0000), or PEN(C:#FF0000FF)
w
: Pen Width, expressed as a numeric value with units (g, px, pt, mm, cm, in)Suggested default: 1 pixel
Examples: PEN(c:#FF0000,w:5px), PEN(w:3pt), PEN(w:50g)
p
: Pattern. To create dash lines. A list of pen-down/pen-up distancesExamples:
id
: Comma-delimited list of Pen Names or Ids For systems that identify pens with a name or an id. The names in the comma-delimited list of ids are scanned until one is recognized by the target system. Pen Ids can be either system-specific ids (see further below) or be one of the pre-defined OGR pen ids for known line patterns. The id parameter should always include one of the OGR ids at the end of the comma-delimited list of ids so that an application never has to rely on understanding system-specific ids.Here is the current list of OGR pen ids (this could grow time):
ogr-pen-0: solid (the default when no id is provided)
ogr-pen-1: null pen (invisible)
ogr-pen-2: dash
ogr-pen-3: short-dash
ogr-pen-4: long-dash
ogr-pen-5: dot line
ogr-pen-6: dash-dot line
ogr-pen-7: dash-dot-dot line
ogr-pen-8: alternate-line (sets every other pixel)
System-specific ids are very likely to be meaningful only to that specific system that created them. The ids should start with the system's name, followed by a dash (-), followed by whatever information is meaningful to that system (a number, a name, a filename, etc.). e.g. "mapinfo-5", or "mysoft-lines.sym-123", or "othersystems-funnyline"
System-specific ids are allowed in order to prevent loss of information when dealing with data from systems that store line patterns in external files or that have their own pre-defined set of line styles (for instance, to do a MapInfo MIF to TAB translation without any loss.
Examples:
PEN(c:#00FF00,id:"ogr-pen-0") - simple solid line
PEN(c:#00FF00,id:"mapinfo-5,ogr-pen-7") - corresponds to MapInfo's Pen #5, and a system that can't understand MapInfo pens falls back on the default "ogr-pen-7" pen (dot-dot line).
cap
: Pen Cap - Set the shape of end points of lines."cap:b" - Butt: The ends of the line don't extend beyond the end points. This is the default.
"cap:r" - Round: Terminate lines with a circle whose diameter is equal to the line width.
"cap:p" - Projecting: Similar to Butt, but the ends of the line extend by half of line width beyond the end points.
j
: Pen Join - Set the shape of the join point (vertex) of lines."j:m" - Miter: Extend the outer edge of the lines until they touch. This is the default.
"j:r" - Rounded: Join lines with an arc whose center is at the join point and whose diameter is equal to the line width.
"j:b" - Bevel: Join the lines with butt end caps and fill the resulting triangular notch at the join position.
dp
: Perpendicular Offset, expressed as a numeric value units (g, px, pt, mm, cm, in)Offset from the line center. If the offset is negative then the pen will be drawn left of the main segment and right otherwise.
l
: Priority Level - Numeric value defining the order in which style parts should be drawn.Lower priority style parts are drawn first, and higher priority ones are drawn on top. If priority level is unspecified, the default is 1.
2.4 Brush Tool Parameters
Applicable geometry types:
Point: Not applicable.
Polyline: Not applicable.
Polygon: Defines the way the surface of a polygon is filled.
Here is the current list of BRUSH tool parameters. Note again that that this list may be extended in the future, and all parameters are optional:
fc
: Brush ForeColor, expressed in hexadecimal (#RRGGBB[AA]). Used for painting the brush pattern itself.[AA]: the last 2 digits define the alpha channel value, with 0 being transparent and FF being opaque. The default is FF (opaque)
Suggested default: 50% grey (c:#808080)
Example: BRUSH(fc:#FF0000)
bc
: Brush BackColor, expressed in hexadecimal (#RRGGBB[AA]). Used for painting the area behind the brush pattern.[AA]: the last 2 digits define the alpha channel value, with 0 being transparent and FF being opaque. The default is FF (opaque)
Suggested default: transparent (c:#FFFFFF00)
Example: BRUSH(fc:#FF0000,bc:#FFEEDD)
id
: Brush Name or Brush Id - Comma-delimited list of brush names or ids. The names in the comma-delimited list of ids are scanned until one is recognized by the target system.Brush Ids can be either system-specific ids (see furtherbelow) or be one of the pre-defined OGR brush ids for well known brush patterns. The id parameter should always include one of the OGR ids at the end of the comma-delimited list of ids so that an application never has to rely on understanding system-specific ids.
Here is the current list of OGR brush ids (this could grow over time):
ogr-brush-0: solid foreground color (the default when no id is provided)
ogr-brush-1: null brush (transparent - no fill, irrespective of fc or bc values
ogr-brush-2: horizontal hatch
ogr-brush-3: vertical hatch
ogr-brush-4: top-left to bottom-right diagonal hatch
ogr-brush-5: bottom-left to top-right diagonal hatch
ogr-brush-6: cross hatch
ogr-brush-7: diagonal cross hatch
Like with Pen Ids, system-specific brush ids are very likely to be meaningful only to that specific system that created them. The ids should start with the system's name, followed by a dash (-), followed by whatever information is meaningful to that system (a number, a name, a filename, etc.).
The following conventions will be used for common system-specific brush ids:
"bmp-filename.bmp" for Windows BMP patterns
Other conventions may be added in the future (such as vector symbols, WMF, etc).
a
: Angle - Rotation angle (in degrees, counterclockwise) to apply to the brush pattern.s
: Size or Scaling Factor - Numeric value with or without units.If units are specified, then this value is the absolute size to draw the brush or symbol. If no units are specified then it is taken as a scaling factor relative to the symbol's default size.
dx
,dy
: Spacing, expressed as a numeric value with units (g, px, pt, mm, cm, in)If filling an area using point symbols, these values will define the spacing to use between them. "dx" is the horizontal distance between the center of two adjacent symbols and "dy" is the vertical distance. The default is to use the symbol's bounding box width and height for dx and dy respectively.
l
: Priority Level - Numeric value defining the order in which style parts should be drawn.Lower priority style parts are drawn first, and higher priority ones are drawn on top. If priority level is unspecified, the default is 1.
2.5 Symbol Tool Parameters
Applicable geometry types:
Point: Place a symbol at the point's location
Polyline: Place symbols along the polyline, either at each vertex, or equally spaced.
Polygon: Place the symbols on the outline of the polygon.
Here is the current list of SYMBOL tool parameters. Note again that that this list may be extended in the future, and all parameters are optional:
id
: Symbol Name or Id - Comma-delimited list of symbol names or ids.The names in the comma-delimited list of ids are scanned until one is recognized by the target system.
Symbol Ids can be either system-specific ids (see further below) or be one of the pre-defined OGR symbol ids for well known symbols. The id parameter should always include one of the OGR ids at the end of the comma-delimited list of ids so that an application never has to rely on understanding system-specific ids.
Here is the current list of OGR symbol ids (this could grow over time):
ogr-sym-0: cross (+)
ogr-sym-1: diagcross (X)
ogr-sym-2: circle (not filled)
ogr-sym-3: circle (filled)
ogr-sym-4: square (not filled)
ogr-sym-5: square (filled)
ogr-sym-6: triangle (not filled)
ogr-sym-7: triangle (filled)
ogr-sym-8: star (not filled)
ogr-sym-9: star (filled)
ogr-sym-10: vertical bar (can be rotated using angle attribute to produce diagonal bar)
Like with Pen Ids, system-specific symbol ids are very likely to be meaningful only to that specific system that created them. The ids should start with the system's name, followed by a dash (-), followed by whatever information is meaningful to that system (a number, a name, a filename, etc.).
The following conventions will be used for common system-specific symbol ids:
"bmp-filename.bmp" for Windows BMP symbols
"font-sym-%d" for a font symbols, where %d is a glyph number inside a font, font family is defined by f style field.
Other conventions may be added in the future (such as vector symbols, WMF, etc.)
a
: Angle - Rotation angle (in degrees, counterclockwise) to apply to the symbol.c
: Symbol Color, expressed in hexadecimal (#RRGGBB[AA])[AA]: the last 2 digits define the alpha channel value, with 0 being transparent and FF being opaque. The default is FF (opaque)
Suggested default symbol color: black (c:#000000)
Example
SYMBOL(c:#FF0000)
o
: Symbol Outline Color, expressed in hexadecimal (#RRGGBB[AA]).If this parameter is set, an additional halo or border of this color is drawn around the symbol.
s
: Size or Scaling Factor - Numeric value with or without units.If units are specified, then this value is the absolute size to draw the symbol. If no units are specified then it is taken as a scaling factor relative to the symbol's default size.
dx
,dy
: X and Y offset, of the symbol's insertion point, expressed as a numeric value with units (g, px, pt, mm, cm, in)Applies to point geometries, and to symbols placed at each vertex of a polyline.
ds
,dp
,di
: Spacing parameters for symbols spaced along a line, expressed as a numeric value with units (g, px, pt, mm, cm, in).ds
is the step to use when placing symbols along the line. By default, symbols applied to a feature with a line geometry are placed at each vertex, butsetting "ds" triggers the placement of symbols at an equal distance along the line. "ds" has no effect for a feature with a point geometry.dp
can be used together with "ds" to specify the perpendicular distance between the symbols' center and the line along which they're placed.di
can be used to specify an initial offset from the beginning of the line.Example
SYMBOL(id:123, s:5, di:5px, ds:50px)
l
: Priority Level - Numeric value defining the order in which style parts should be drawn.Lower priority style parts are drawn first, and higher priority ones are drawn on top. If priority level is unspecified, the default is 1.
f
: Font Name - Comma-delimited list of fonts names.Works like the CSS font-family property: the list of font names is scanned until a known font name is encountered.
Example
SYMBOL(c:#00FF00,s:12pt,id:"font-sym-75,ogr-sym-9",f:"MapInfo_Cartographic")
2.6 Label Tool Parameters
Applicable geometry types:
Point: Place a text label at the point's location
Polyline: Place text along the polyline.
Polygon: Place a label at the centroid of the polygon. All parameters behave exactly as if the geometry was a point located at the polygon's centroid.
Here is the current list of LABEL tool parameters. Note again that that this list may be extended in the future, and all parameters are optional:
f
: Font Name - Comma-delimited list of fonts names.Works like the CSS font-family property: the list of font names is scanned until a known font name is encountered.
Example
LABEL(f:"Noto Sans, Helvetica", s:12pt, t:"Hello World!")
s
: Font Size, expressed as a numeric value with units (g, px, pt, mm, cm, in).In the CAD world, font size, or "text height", determines the height of a capital letter - what typographers call "cap height". But in the worlds of typesetting, graphics and cartography, font size refers to the "em height" of the font, which is taller than the cap height. This means that text assigned a height of 1 inch in a DXF file will look larger (often about 45% larger) than 72-point text in a PDF file or MapInfo map. At present, GDAL vector drivers treat the "s:" style string value as whichever font size measurement (cap height or em height) is used natively by that format, which may result in incorrect text sizing when using the ogr2ogr tool. This parameter could be subject to clearer specification in the future.
t
: Text String - Can be a constant string, or a reference to an attribute field's value.If a double-quote character or backslash () character is present in the string, it is escaped with a backslash character before it.
Examples
LABEL(f:"Arial, Helvetica", s:12pt, t:"Hello World!") LABEL(f:"Arial, Helvetica", s:12pt, t:"Hello World with escaped \\"quotes\" and \\\backslash!") LABEL(f:"Arial, Helvetica", s:12pt, t:{text_attribute})
a
: Angle - Rotation angle (in degrees, counterclockwise).c
: Text Foreground Color, expressed in hexadecimal (#RRGGBB[AA]) Suggested default: black (c:#000000)b
: Text Background Color - Color of the filled box to draw behind the label, expressed in hexadecimal (#RRGGBB[AA]). No box drawn if not set.o
: Text Outline Color - Color of the text outline (halo in MapInfo terminology), expressed in hexadecimal (#RRGGBB[AA]). No outline if not set.h
: Shadow Color - Color of the text shadow, expressed in hexadecimal (#RRGGBB[AA]). No shadow if not set.w
: Stretch - The stretch factor changes the width of all characters in the font by the given percentage. For example, a setting of 150 results in all characters in the font being stretched to 150% of their usual width. The default stretch factor is 100.m
: Label Placement Mode - How the text is drawn relative to the feature's geometry."m:p" - The default. A simple label is attached to a point or to the first vertex of a polyline.
"m:l" - Text is attached to the last vertex of a polyline. A PEN tool can be combined with this LABEL tool to draw the polyline as a leader to the label.
"m:s" - Stretch the text string along a polyline, with an equal spacing between each character.
"m:m" - Place text as a single label at the middle of a polyline (based on total line length).
"m:w" - One word per line segment in a polyline.
"m:h" - Every word of text attached to polyline is placed horizontally in its segment, anchor point is a center of segment.
"m:a" - Every word of text attached to polyline is stretched to fit the segment of polyline and placed along that segment. The anchor point is a start of a segment.
p
: Anchor Position - A value from 1 to 12 defining the label's position relative to the point to which it is attachedThere are four vertical alignment modes: baseline, center, top and bottom; and three horizontal modes: left, center and right.
Currently, the precise interpretation of these values (for example, whether accents on uppercase letters sit above or below the alignment point with p:7) differs from file format to file format. This parameter could be subject to clearer specification in the future.
dx
,dy
: X and Y offset of the label's insertion point, expressed as a numeric value with units (g, px, pt, mm, cm, in).Applies to text placed on a point, or at each vertex of a polyline.
dp
: Perpendicular Offset for labels placed along a line, expressed as a numeric value with units (g, px, pt, mm, cm, in)."dp" specifies the perpendicular distance between the label and the line along which it is placed. If the offset is negative then the label will be shifted left of the main segment, and right otherwise.
bo
: Bold - Set to 1 for bold text. Set to 0 or omitted otherwise.it
: Italic - Set to 1 for italic text. Set to 0 or omitted otherwise.un
: Underline - Set to 1 for underlined text. Set to 0 or omitted otherwise.st
: Strikethrough - Set to 1 for struck-through text. Set to 0 or omitted otherwise.l
: Priority Level - Numeric value defining the order in which style parts should be drawn.Lower priority style parts are drawn first, and higher priority ones are drawn on top. If priority level is unspecified, the default is 1.
2.7 Styles Table Format
For file formats that support tables of styles, then the predefined styles would be stored in that format.
For file formats that do not support tables of styles, then the style table could be stored in a text file with a .ofs (OGR Feature Styles) extension and the same basename as the dataset. This would apply to formats like Esri Shapefile.
Here is an example of a .ofs file:
#OFS-Version: 1.0
#StyleField: "style"
DefaultStyle: PEN(c:#000000)
road: PEN(c:#FF0000,w:5px)
lake: BRUSH(fc:#0000FF);PEN(c:#000000)
campsite: SYMBOL(c:#00FF00,id:"points.sym-45,ogr-sym-7")
label: LABEL(f:"Times New Roman",s:12pt,t:{text_attribute})
The first line is a signature with a version number, which must be present.
The second line (StyleField: "style") is the name of the attribute field in which the Feature Style String is stored for each object in the corresponding layer. This is optional, if not set, then the objects in the layer will all share the same style defined in DefaultStyle.
The third line (DefaultStyle:...) defines the style that applies by default to all objects that have no explicit style.
Then the list of style definitions follow.
2.8 Using OGR SQL to transfer the style between the data sources
You can use the OGR_STYLE special field to extract the feature level style, and ogr2ogr can be used to transfer the style string between data sources according to the following example:
ogr2ogr -f "ESRI Shapefile" -sql "select *, OGR_STYLE from rivers" rivers.shp rivers.tab
Without specifying the length of the style field, the output driver may truncate the length to a default value. Therefore it may be necessary to specify the target length manually, like:
ogr2ogr -f "ESRI Shapefile" -sql "select *, CAST(OGR_STYLE AS character(255)) from rivers" rivers.shp rivers.tab
OGR is aware of using the OGR_STYLE field if it exists, and OGRFeature::GetStyleString will return the value of this field if no style string has been specified programmatically.
3. OGR Support Classes
The OGRFeature
class has member functions
OGRFeature::GetStyleString()
, OGRFeature::SetStyleString()
and OGRFeature::SetStyleStringDirectly()
which may be used to interact with a feature's style string as a C-style
string. Additionally, there are OGRFeature::GetStyleTable()
, OGRFeature::SetStyleTable()
and
OGRFeature::SetStyleTableDirectly()
for managing style tables as instances of the
OGRStyleTable
class.
The OGRLayer
and GDALDataset
classes also have OGRLayer::GetStyleTable()
,
OGRLayer::SetStyleTable()
and OGRLayer::SetStyleTableDirectly()
member functions.
To parse style strings, the OGRStyleMgr
class is used. Each style tool in the string
is accessed as an instance of the OGRStyleTool
class. Lastly, four helper classes exist,
one for each tool (OGRStylePen
,
OGRStyleBrush
,
OGRStyleSymbol
,
OGRStyleLabel
), with each available
parameter represented by a getter and setter member function. To
understand these classes better, it may be useful to read the
ogr_featurestyle.h
and
ogrfeaturestyle.cpp
code files.
Here is some example C++ code:
OGRStyleTable oStyleTable;
OGRStyleMgr *poStyleMgr = new OGRStyleMgr(&oStyleTable);
// Create a new style in the style table by specifying the whole style string
if (poStyleMgr->AddStyle("@Name","PEN(c:#123456;w:10px);BRUSH(c:#345678)"))
{
poStyleMgr->SetFeatureStyleString(poFeature,"@Name",TRUE)
// or
poStyleMgr->SetFeatureStyleString(poFeature,"PEN(c:#123456,w:10px);BRUSH(c:#345678)",FALSE)
}
oStyleTable->SaveStyleTable("ttt.tbl");
// Create a new style in the style table by specifying each tool (part) as a string
poStyleMgr->InitStyleString();
poStyleMgr->AddPart("PEN(c:#123456,w:10px)");
poStyleMgr->AddPart("BRUSH(c:345678)");
poStyleMgr->AddStyle("@Name");
poStyleMgr->SetFeatureStyleString(poFeature,"@Name",TRUE);
oStyleTable->SaveStyleTable("ttt.tbl");
// Create a new style in the style table using the style tool helper classes
OGRStyleTool *poStylePen = new OGRStylePen;
poStylePen->SetColor("#123456");
poStylePen->SetUnit(OGRSTUPixel);
poStylePen->SetWidth(10.0);
poStyleMgr->AddPart(poStylePen);
delete poStylePen;
// Reading a style
OGRStyleTool *poStyleTool;
poStyleMgr->GetStyleString(poFeature);
for (int iPart = 0; iPart < poStyleMgr->GetPartCount(); iPart++)
{
poStyleTool = GetPart(iPart);
switch (poStyleTool->GetType())
{
case OGRSTCPen:
poStylePen = (OGRStylePen *)poStyleTool;
pszColor = poStylePen->Color(bDefault);
if (bDefault == FALSE)
poStylePen->GetRGBFromString(pszColor, nRed, nGreen,
nBlue, nTrans);
else
// Color not defined
dfWidth = poStylePen->Width(bDefault);
if (bDefault == FALSE)
// Use dfWidth
else
// dfWidth not defined
:
:
}
}
Revision history
Version 0.016 - 2018-12-03 - Andrew Sudorgin Restored and documented font property for point symbols
Version 0.015 - 2018-01-08 - Alan Thomas Update outdated material; minor changes to BRUSH 'id' and LABEL 't', 'bo', 'it', 'un', 'st'; clarify BRUSH 'fc', 'bc', SYMBOL 'o' and LABEL 's', 'w', 'p'
Version 0.014 - 2011-07-24 - Even Rouault Mention the escaping of double-quote characters in the text string of a LABEL (ticket #3675)
Version 0.013 - 2008-07-29 - Daniel Morissette Added 'o:' for font point symbol outline color (ticket #2509)
Version 0.012 - 2008-07-21 - Daniel Morissette Added 'o:' for text outline color and updated 'b:' to be specifically a filled label background box (ticket #2480)
Version 0.011 - 2008-02-28 - Tamas Szekeres Note about OGR SQL to transfer the style between the data sources
Version 0.010 - 2006-09-23- Andrey Kiselev Added label styles 'w', 'st', 'h', 'm:h', 'm:a', 'p:{10,11,12}'
Version 0.009 - 2005-03-11- Frank Warmerdam Remove reference to OGRWin, move into ogr distribution
Version 0.008 - 2001-03-21- Frank Warmerdam Fix minor typos (h:12pt instead of s:12pt in examples)
Version 0.008 - 2000-07-15 - Stephane Villeneuve Remove style table in Layer. Add forecolor and backcolor to brush.
Version 0.007 - 2000-06-22 - Daniel Morissette Fixed typo and added offset param for PEN.
Version 0.006 - 2000-06-20 - Daniel Morissette Added the OGR-Win idea and made small changes here and there.
Version 0.005 - 2000-06-12 - Daniel Morissette Allow passing of comma-delimited list of names in PEN's "id" parameter. Defined system-independent pen style names.
Version 0.004 - 2000-06-09 - Stephane Villeneuve Added PEN cap and join parameters More clearly defined the API
Version 0.003 - 2000-02-15 - Daniel Morissette First kind-of-complete version.


Web Designer
Hello, the name is Jasfer Cid B. Casibang, The maker of this website. I was born and raised in the philppine and I did this to help out and plus it was fun trying to see if I still have the determination of making websites and most of it was fun.
While its not the best its honest work and more importantly I get to help out and brighten someone’s day so I made this. Anyway an aspiring game dev like Jose I dream of making an RTS staring the philippines spanish colonial era up to the modern and space age as I believe that my history is as colorful and interesting as the people that it represents.


Clintonville Neighborhood Greenways
We're building a network of streets in Clintonville where people biking and walking are given priority.
It's in My
Neighborhood
Clintonville Neighborhood Greenways is a grassroots project initiated by residents of Clintonville for the
residents of Clintonville.
It Connects Me to
Where I Want to Go
Clintonville Neighborhood Greenways connect to restaurants, shopping, schools, Whetstone Park,
the library, and much more.
It's Safe for Me
and My Family
Neighborhood Greenways make streets slower and quieter, improving safety for everyone and making our
neighborhood more livable.
Phase 1 is Red (September 2018). Future expansion is Blue.
 These slower, quieter streets create safe routes to bike and walk around Clintonville without using High Street or Indianola. This encourages more people to bike and walk to work, to shop, to socialize, and to just have fun.
Neighborhood Greenways are designed to feel safe for people of all ages and abilities. They appeal to a large cross-section of people, sometimes referred to as the “bike curious”, who would bike and walk more if they felt safe on the roads.
Greenways benefit the whole neighborhood
- By creating a quieter, more pleasant street environment that improves safety for everyone.
- By building a stronger sense of community and neighborhood identity. With more people biking and walking, there are more opportunities for social encounters where neighbors and friends can meet and interact. These impromptu meetings make the neighborhood friendlier, safer, and more pleasant for everyone.
- By encouraging increased patronage of local businesses. People biking and walking visit local businesses more frequently and spend more money over time than people using other types of transportation.
- By raising property values. Studies consitently show that greenways and shared use paths increase home values. The National Association of Homebuilders and the National Association of Realtors report that greenways are one of the top amenities homebuyers want.
- By creating more "eyes on the street". More people and a slower street environment result in more awareness of neighborhood activities.
 Cities with neighborhood greenways include Rochester NY, Minneapolis MN, Madison WI, Columbia MO, Wilmington NC, Gainesville FL, Tulsa OK, Tucson AZ, Albuquerque NM, Seattle WA, Berkeley CA, and Portland OR.
Want to learn more?
- Read about us in The Columbus Dispatch and Columbus Underground
- See the Phase 1 Route and Design.
- Read our Frequently Asked Questions.
- Get the latest news on our Updates page.
- Watch a Video of neighborhood greenways in Portland.
Sign up for our mailing list
We'll send you periodic updates, no more than twice a month.
{% include mail_chimp_signup.html %}About us
Clintonville Neighborhood Greenways was started by 5 residents of Clintonville: Will Koehler, Alex Smith, Emily Monnig, Mike Anderson, and Brian Laliberte. We are inspired by a shared vision of a community bustling with people; a neighborhood where streets are shared safely by everyone, walking, biking, and driving.
If you have questions, or want to get involved, please contact us: hello@clintonvillegreenways.org


Today’s leaders embrace automation because they know it’s the secret to overcoming the mind-bending pace of today’s digital change. True visionaries are now using intelligent automation to tackle the new digital world where they are masters of competitive advantage. Their latest recruits include machines and software intelligence that they are now being used to bring fundamental changes to how businesses and individuals work; also bringing accelerated, elevated, and strengthened capabilities that complement their human supervisors. Together, they are re-imagining and re-defining change.
Scorpion is emerging as a key developer of computer systems that are able to perform tasks that normally require humans, such as visual perception, speech recognition, decision-making processes, translation between languages, and other endless application scenarios.
Scorpion believes the secure and accurate management if your daya is mission critical. Our focus on data management is the development to execute your organizations processes, architectures, policies, practices and procedures with the most secure and efficient technologies available.
Digital marketing encompasses all marketing efforts that use an electronic device or the internet. Scorpion helps businesses leverage digital channels such as website development, search engine optimization, social media, email, branding, reputation management, and many other tools to connect with current and prospective customers and clients.
Software robots don’t just mindlessly reproduce manual activity anymore. They can actually make intelligent decisions just like a human being would, based on dynamic information. Errors and exceptions can be checked along the way. Alternate actions can be chosen when things don't quite work as expected.
Intelligent automation software actually has an “understanding” of your business processes and their permutations. The software takes that knowledge into account when executing automated business process validation to verify that the right outcome occurred.
When changes are made to underlying enterprise applications (like SAP, Oracle, etc.) the automation software can also point out which business processes are going to be impacted by the change - and therefore need to be tested. Intelligent automation can also update its own understanding and description of those business processes by incorporating what’s changed into its database of existing processes.
Scorpion Engineering and Development (Scorpion) is a technology and data management innovation company headquartered in Orlando, FL. We specialize in providing advanced technology solutions and services to federal agencies, state agencies, and corporations throughout the United States. Leveraging intelligent automation, a multi-disciplinary collaborative environment, and its substantial intellectual property portfolio, Scorpion excels in developing concepts into market-focused products and customer-driven solutions.
Scorpion’s solutions provide robust high-performance infrastructures along with services and tools for the rapid development and deployment of large-scale distributed systems. Scorpion has expertise in service-oriented agent frameworks, cognitive systems, semantic service-oriented architecture, and web services. Scorpion designs solutions compatible with distributed interoperability standards, including standards from N.A.M.E and O.W.A.S.P.
Scorpion uses Human Factors engineering methods to design easy-to-use interfaces that improve human-system functionality, productivity and situational awareness. Scorpion applies current best practices to the design integration of human-machine systems. We create new systems to automate previously un-automated capabilities, apply principles to test new designs in novel conditions, and create designs for existing products or those in development. We conduct cognitive analyses to design interfaces, and run usability tests to assess interfaces, tools and performance. We also create or revise computer interfaces that implement designs for specific products.
Founder / Director of Development
Co-Owner / Director of Sales
Co-Owner / Director of Support


--- layout: post esbma_id: 1180 title: Geek Gauntlets date: 2003-08-07 13:42:44 keywords: mfg_strategy teaser: To reach mainstream customers, we sometimes need to ignore our own preferences and just do what the customers want. Non-geeks in marketing generally have no trouble with this. Once they decide what the market prefers, all they want to do is get that product into the customer's hands. They don't have strong opinions about technology, so they don't have trouble separating customer preferences from their own. ---
When we talk about Marketing for Geeks, we obviously talk a lot about marketing. But we also need to talk about geeks. After all, we chose software as our primary career field, and that choice says something about the way we are wired inside. When we do coding or design, that wiring is a strength, but it can be a weakness when we start getting involved in marketing.
What do customers want?
 Sounds easy, right? But how do we know what they want?
Actually there are lots of ways to figure out what a market wants, none of which are terribly accurate, most of which are quite expensive. In the end, we can spend lots of time and money and still we have no guarantees. Wouldn't it be easier if our prospective customers just happened to want the same things that we want? Then we could simply build products for ourselves, comfortably assured that other people will like them as much as we do.
A friend of mine wants to sell a cool technology solution to the trucking industry. Unfortunately, he is a geek. He realized right away that it was going to be nearly impossible to sell technology to trucking companies unless he understood trucking. So he went to truck driving school. He got his truck drivers license. He got a job driving a load of paper every day between Chicago and Peoria. He got layed-off. He bought his own truck. He started his own freight company. His product idea is getting better because he is learning what the people in his market really need.
This approach may seem extreme, but it's a great example of an important concept: It is much easier to sell products to people who are not so different from yourself.
However...
... although being similar to your customers is a powerful advantage, it is not enough. Your own preferences will never be an exact match for the wants of your market segment.
This is true even here at SourceGear. We are a company of software developers, selling tools for use by other software developers. Can a small ISV and its customers possibly be any more similar? It seems like our preferences should be a perfect match for the preferences of people in our market, but it just doesn't work out that way. We regularly hear from people who are trying to use our products in ways that never occurred to us.
If a developer tools company can see the gap between ourselves and our customers, think how much bigger that gap must be in any other market.
Getting Fooled by the Early Adopters
All too often, companies learn this lesson as they lie dead at the bottom of the chasm. Because of the way markets are divided into stages, it sometimes seems like our customers actually do have the same preferences that we do.
In every market, the first stage is the Early Adopters. A lot of these people are geeks, just like we are. If we build a product to match our own preferences, the Early Adopters might actually buy it, since they're not altogether different from us. We might even start to believe that we've built a great product which will be popular with the mainstream customers on the other side of the chasm. If so, we are in for a big shock.
This effect is perhaps most visible by cruising around the SourceForge website. There are thousands of small open source projects there, most of which have very few developers and very few users. Typically an open source project begins when a developer wants to "scratch his own itch". He creates an app for himself, specifically designed to solve some problem he is experiencing. He makes his app open source and expects hordes of people to start downloading it. A few people do notice the app and discover it is exactly what they were looking for. But the hordes don't come. There is a big differences between solving your own problems and solving mainstream problems.
Gauntlets of Fumbling
To reach mainstream customers, we sometimes need to ignore our own preferences and just do what the customers want. Non-geeks in marketing generally have no trouble with this. Once they decide what the market prefers, all they want to do is get that product into the customer's hands. They don't have strong opinions about technology, so they don't have trouble separating customer preferences from their own.
Not so with us geeks. We care too much about technology. We chose software development careers because we love technology for its own sake. We fight amongst ourselves in religious battles that seem arcane and irrelevant to normal people. We debate vi against emacs, Linux against Windows, C# against Java, RSS against Atom. We have strong opinions and we make them visible to everyone around us.
And when we get involved in marketing, we can stumble over those opinions. We need to talk about what customers want, but our own preferences get in the way. We bring our technology prejudices and biases to the discussion, often without ever being aware of the problems they can cause.
The whole situation is like wearing Gauntlets of Fumbling. Remember NetHack? If your character is wearing these useless gloves, everything is more difficult. A similar effect happens when we bring our weird technology opinions into a discussion about what customers want. We slow everything down, and we make the whole process very clumsy.
Stories
And yet, people do buy commercial version control tools. In fact, I can name at least a dozen version control vendors which I believe are profitable. The aggregate annual revenue in this market segment is a nine digit number.
An explanation of why all this revenue can coexist with an open source alternative is beyond the scope of this article. Suffice it to say that if you are completely bewildered at the fact that anyone uses commercial tools, then you might want to find a scroll of identify and see what kind of gloves you are wearing. :-)
This guy brings a negative bias about Passport into the discussion. Perhaps he got his opinions from stuff he sees in the press or on Slashdot. Perhaps those negative opinions are justified. But if a substantial fraction of our target market wants Vault to understand Passport authentication, we need to lay our bias aside and investigate the issue objectively. Our biases don't help us figure out how to make the best product for the market.
- Our SourceOffSite Collab product was heavily affected by my own religious technology opinions. Our users do like the product, but we invested a lot of effort under the hood in things that don't benefit the user at all.
- Even Vault has suffered from my mistakes. As a result of my advocacy, the label feature in Vault is somewhat different from its SourceSafe counterpart. Our design is more "neato", but quite a few of our users really wish we had just done plain-old-boring SourceSafe-style labels.
My own Gauntlets of Fumbling are well-worn and comfortable. Someday I will learn that nobody else cares about my technology whims. :-)
Gauntlets of Dexterity
So it's important to learn how to set aside our own preferences when appropriate. However, we don't want to also set aside the deep technology understanding we have. Those two things come together, like the two sides of a coin. The religious preferences are inseparable from the expertise. The former is an obstacle to marketing discussions, but the latter is a tremendous asset. Stretching my NetHack analogy a bit further, using our understanding of technology in marketing is like wearing Gauntlets of Dexterity.
Lots of strategic marketing decisions are better made by someone who really understands the technologies involved. Joel Spolsky claims that "no software company can succeed unless there is a programmer at the helm". I am inclined to agree, and I further argue that "what's good for the CEO is good for the marketing team".
I write about Marketing for Geeks because, quite frankly, marketing needs us. Lots of marketing decisions are actually technology decisions in disguise. Geeks understand what is going on under the hood. Our technology depth allows us to process decisions with greater dexterity. We can see through the abstractions. We know the technical side effects of our choices, and we know how users are going to be affected. When marketing decisions get made without our expertise, big mistakes can happen.
A good example right now is deciding whether to migrate a desktop application from VB6 to VB.NET. Geeks want to be using the latest tools, but do users want to install the 20 meg .NET runtime? How will they get it? Do our customers have cable modems? Will something go wrong?
The Vault client is written in C# and therefore requires the .NET Framework on the desktop side. For us, this is no problem, since our customer base is very likely to have already installed it. But selling a desktop app to normal people would be an entirely different matter.
This can be a tough decision for application developers today. It is a technology choice, so it really needs to be done with the help of geeks. But it has marketing implications, so it's important to set aside our own preferences and keep a pure focus on the user.
 :-)
Your geekiness is your strength, and it makes you a good developer. But there is a time to talk about what normal people want. When you do marketing stuff, wear the right gloves. Set aside part of your geekiness, just for a little while.
Let's close this piece with a bit of humor. For those of you who missed my talk at Gnomedex, here are a few clues to further help distinguish geeks from normal people. :-)
Top
Eight List:
Clues that You Might be a Geek
0 -- You number things from zero instead of one, because that's what a C programmer would do.
1 -- You love numbers that are powers of two.


Get chunks of XML scholarly articles without having to know how to work with XML. Custom mappers for each publisher and for each article section pull out the information you want. Works with outputs from package 'fulltext', 'xml2' package documents, and file paths to XML documents.
| Version: | 0.1.0 |
| Imports: | xml2 (≥ 1.1.1), data.table |
| Suggests: | fulltext (≥ 1.0.1), testthat |
| Published: | 2018-10-14 |
| Author: | Scott Chamberlain [aut, cre] |
| Maintainer: | Scott Chamberlain <sckott at protonmail.com> |
| BugReports: | https://github.com/ropensci/pubchunks/issues |
| License: | MIT + file LICENSE |
| URL: | https://github.com/ropensci/pubchunks |
| NeedsCompilation: | no |
| Language: | en-US |
| Materials: | README NEWS |
| CRAN checks: | pubchunks results |
| Reference manual: | pubchunks.pdf |
| Package source: | pubchunks_0.1.0.tar.gz |
| Windows binaries: | r-devel: pubchunks_0.1.0.zip, r-release: pubchunks_0.1.0.zip, r-oldrel: pubchunks_0.1.0.zip |
| OS X binaries: | r-release: pubchunks_0.1.0.tgz, r-oldrel: pubchunks_0.1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=pubchunks to link to this page.


10. Reference application
10.1. Transport modules coding in XML geometry file
Type name |
Transport class |
Description |
|---|---|---|
cylinder |
mcTransportCylinder |
Solid cylinder |
cone |
mcTransportCone |
Solid cone |
prism |
mcTransportPrism |
Solid prism |
wedge |
mcTransportWedge |
Solid rectangle cylinder |
ring |
mcTransportRing |
Solid ring |
conicalring |
mcTransportConicalRing |
Solid ring with focused edges |
conicalhole |
mcTransportConicalHole |
Solid ring with hole and all edges focused |
rectanglering |
mcTransportRectangleRing |
Solid rectangle ring |
jaw_pair |
mcTransportJawPairRounded |
Pair of solid prism, representing collimator jaws |
jaw_pair_focused |
mcTransportJawPairFocused |
Pair of solid prism with focused internal edges, representing collimator jaws |
rectanglepolygonsidehole |
mcTransportRectanglePolygonSideHole |
Solid prism with rectangle hole which internal edge is defined by arbitrary polygon |
mlc |
mcTransportMLC |
MLC modelling module |
gridcylinder |
mcTransportCylinderStack |
Stack of nested cylinders with space between them |
planefilter |
mcTransportPlaneFilter |
Transparent infinite plane used for hosting objects like scoring |
etrap |
mcETransportTrap |
An other infinite plane, which kills particles after processing in scoring |
rectangletrap |
mcTransportRectangleTrap |
Rectangular trap, which kills particles except those that go through the internal hole or onside the transport |
spheretrap |
mcTransportSphereTrap |
Spherical trap that kills particle after scoring |
axial_splitter |
mcTransportAxialSymmetricSplitter |
Splits particles in cylindrical symmetric cases with eventual rotation around Z axis and preserving total weight |
simple_splitter |
mcTransportSimpleSplitter |
Generates copies of particles while keeping total weight |
slab |
mcTransportSlab |
Simple infinite slab |
ptlasvegas |
mcPTLasVegas |
Las Vegas phantom for testing portal imaging systems in radiation therapy units |
esphere |
mcETransportSphere |
Solid sphere |
e_convex_polygon_circle |
mcETransportConvexPolygonCircle |
Cylindrically symmetric solid object formed by polygon rotation around Z axis |
Next is an example of code, which parses geometry configuration file and creates network of transport objects.
if (_wcsicmp(geomType.c_str(), L"ptlasvegas") == 0)
{
t = new mcPTLasVegas(origin, normal, xaxis);
}
else if (_wcsicmp(geomType.c_str(), L"esphere") == 0)
{
t = new mcETransportSphere(origin, normal, xaxis, radius);
}
else if (_wcsicmp(geomType.c_str(), L"e_convex_polygon_circle") == 0)
{
t = new mcETransportConvexPolygonCircle(origin, normal, xaxis, poly_z, poly_x);
}
10.1.1. Module “cylinder”
Class: |
mcTransportCylinder |
Description: |
Cylinder object |
Example: |
10.1.2. Module “rectanglepolygonsidehole”
Class: |
mcTransportRectanglePolygonSideHole |
Description: |
Cylindrically symmetric object with shaped by polygon hole |
Example: |
10.2. Composite transport modules coding in XML geometry file
Type name |
Transport class |
Description |
|---|---|---|
group |
mcTransport |
Embedding other transport as regions |
embedding |
mcTransport |
Embedding nested transport modules |
embedded_group |
mcTransportEmbeddedGroup |
Group of transport modules with arbitrary order |
linear_chain |
mcTransportLinearChain |
Z ordered chain of transports that pass particles to neighbors |
10.2.1. Module “group”
Class: |
mcTransport |
Description: |
Not a real object. It is a special construction to group other object. Group is treated by shower as a single object. I.e. it looks like a module in z-ordered chain of modules. |
Example: |
<!--CyberKnife primary collimator with aluminum filter layer-->
<module type="group" name="PRI_1">
<position unit="cm" x="0" y="0" z="-78.5" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<module type="ring" name="PRI_1W" medium="W700ICRU" density="1">
<Color r="0" g="0.5" b="0" t="0.5" />
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<size unit="cm" r0="0.24" r1="8.25" height="3.1"/>
</module>
<module type="cylinder" name="PRI_1A" medium="AL700ICRU" density="1">
<Color r="1" g="1" b="1" t="0.5" />
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<size unit="cm" radius="0.24" height="0.85"/>
</module>
</module>
|
Next is a parser code fragment, that demonstrates how content of “group” module description is interpreted. Grouping is implemented through the concept of Regions.
else if (_wcsicmp(geomType.c_str(), L"group") == 0)
{
t = new mcTransport(origin, normal, xaxis);
// Search and parse embedded modules
for (auto node : geometry.Nodes)
{
if (_wcsicmp(node.Name.c_str(), L"module") == 0)
{
mcTransport* region = GeometryParser::ParseTransport(node, media, nThreads);
region->setDefaultScore(nThreads);
t->addRegion(region);
}
}
}
In this code example variable t represents transport module which will be inserted in to the current transport chain. Nested modules will be simulated as regular modules, but under the multiregion transport t roof.
Note
Nested modules coordinate system is defined relatively to the parent module.
In this particular module “group” example two modules are nested to parent module. Their registration in parent as regions means, that after each event of exiting from nested module particles will be tested on possibility of hitting any other region. If so, transport will be delegated to the nearest hitting region. Otherwise particle will exit parent module.
10.2.2. Module “embedding”
Class: |
Can be any transport class, that implements nested transport |
Description: |
Nested set of transport modules. The most external one represents the whole module from the point of view of consuming linear chain of transports. |
Example: |
<?xml version="1.0" encoding="utf-8"?>
<!-- Faddegon experiment geometry with spherical detector -->
<accelerator>
<!--
Objects are sequence of nested objects.
First one is experimental unit as whole (wich can be inserted in other chains).
All its childs are nested as a Russian dole.
First child is most internal object (target in this case).
All child coordinates are defined relatively to the parent.
-->
<module type="embedding" name="ExperimentalUnit">
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<!--Target-->
<!-- Pb (9.13 g/cm2 thick, 17.95 g/cm2 radius RHO= 1.1340E+01 -->
<module type="cylinder" name="Target" medium="PB700ICRU" density="1">
<Color r="1" g="1" b="1" t="0" />
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<size unit="cm" radius="1.58" height="0.805"/>
</module>
<!-- Assume transport in Vacuum (i.e. next will be detector) -->
<!--Spherical detector is requred to atach scoring-->
<module type="spheretrap" name="Detector" medium="H2O700ICRU" density="1">
<Color r="1.0" g="0.5" b="0.5" t="0.8" />
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<size unit="cm" radius="100.0"/>
</module>
</module>
</accelerator>
|
XML configuration file contains nested transports of “embedding” module in the order of internal transports first.
Next is a parser code fragment, that demonstrates how content of “embedding” module description is interpreted. Grouping is implemented through the concept of nested transports, which means russian doll type construction, i.e. nested transport is completely covered by parent transport. Each transport may have only one reference to embedded transport.
else if (_wcsicmp(geomType.c_str(), L"embedding") == 0)
{
// Temporal transport needed for group coordinate system
mcTransport ttmp(origin, normal, xaxis);
mcTransport* eprev = nullptr;
// Search and parse nested transports
for (auto node : geometry.Nodes)
{
if (_wcsicmp(node.Name.c_str(), L"module") == 0)
{
mcTransport* eobj = GeometryParser::ParseTransport(node, media, nThreads);
if (eobj == nullptr)
throw exception("Embedding group should contain only embedding objects");
// Transfer coordinate system from group to world
eobj->MoveToCoordinateSystem(ttmp.MT2W());
eobj->setDefaultScore(nThreads);
if (eprev != nullptr)
{
eprev->setExternalTransport(eobj);
eobj->setInternalTransport(eprev);
}
eprev = eobj;
}
}
t = eprev;
skipInit = true;
}
In this code example variable t represents transport module which will be inserted in to the current transport chain. Nested modules will be simulated by moving particles between internal / external transport until particle leave the most external transport.
Note
Nested modules coordinate system is defined relatively to the parent module.
In this particular module “embedding” example there are two modules. Оne (Target) is inside the other (spherical detector). In contrast to linear chain of transports ordered by increasing Z position nested transport is implemented by setting references in each transport “embedding” module references to external and internal ones. Registration transports in a such a way is provided by setExternalTransport() / setInternalTransport() functions.
10.2.3. Module “embedded_group”
Class: |
mcTransportEmbeddedGroup |
Description: |
Special class with overridden transport, which at transport inside itself detects nearest transport from internal collection which can be hit by particles and pass transport to it. If no internal transport can be hit, particle exits from this module. |
Example: |
<!--
Group of modules consisting of target and
shielding elements and primary collimator hole
-->
<module type="embedded_group" name="ShieldInternalGroup">
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<!--Accelerator part-->
<module type="embedding" name="Accelerator">
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<!--......................-->
</module>
<!--Primary collimator hole-->
<module type="e_convex_polygon_circle" name="PriCollAir"
medium="AIR700ICRU" density="1">
<Color r="0.2" g="0.2" b="1.0" t="0.8" />
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<polygon>
<point z="1.801" x="0.65"/>
<point z="9.799" x="2.6"/>
</polygon>
</module>
</module>
|
XML configuration file contains nested transports of “embedded_group” module in the order of internal transports first.
Next is a parser code fragment, that demonstrates how content of “embedded_group” module description is interpreted. Grouping is implemented through the concept of internal collection of transport modules, which can be hit by the particles in any order.
else if (_wcsicmp(geomType.c_str(), L"embedded_group") == 0)
{
t = new mcTransportEmbeddedGroup(origin, normal, xaxis);
// Search and parse nested transports
for (auto node : geometry.Nodes)
{
if (_wcsicmp(node.Name.c_str(), L"module") == 0)
{
mcTransport* eobj = GeometryParser::ParseTransport(node, media, nThreads);
if (eobj == nullptr)
throw exception("embedded_group internal module parse error");
// Transfer coordinate system from group to world
eobj->MoveToCoordinateSystem(t->MT2W());
((mcTransportEmbeddedGroup*)t)->addTransport(eobj);
}
}
}
In this code example variable t represents transport module which will be inserted in to the current transport chain.
Note
Nested modules coordinate system is defined relatively to the parent module.
In this particular module “embedded_group” example demonstrates how primary collimator hole can be implemented inside the whole shield side by side with electron accelerator inside the same shied object.
10.2.4. Module “linear_chain”
Class: |
mcTransportLinearChain |
Description: |
Special class with overridden transport, which at transport inside itself detects nearest transport from internal collection which can be hit by particles and pass transport to it. If no internal transport can be hit, particle exits from this module. |
Example: |
<module type="linear_chain" name="RadiationHead">
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<module type="embedding" name="ShieldGroup">
<position unit="cm" x="0" y="0" z="0" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<!--......................-->
</module>
<!--Flattening filter-->
<module type="cone" name="Flattenig Filter" medium="W700ICRU" density="1">
<Color r="0.7" g="0.7" b="0.7" t="0.2" />
<position unit="cm" x="0" y="0" z="11" />
<normal x="0" y="0" z="-1" />
<xaxis x="-1" y="0" z="0" />
<size unit="cm" radius="2.4" height="1.0"/>
</module>
<!--Ionization chamber-->
<module type="cylinder" name="IonChamber" medium="AIR700ICRU" density="1">
<Color r="1.0" g="0.5" b="0.0" t="0.7" />
<position unit="cm" x="0" y="0" z="11.5" />
<normal x="0" y="0" z="1" />
<xaxis x="1" y="0" z="0" />
<size unit="cm" radius="6.0" height="2"/>
</module>
<!--......................-->
</module>
|
XML configuration file contains nested transports of “linear_chain” module in the order of internal transports first.
Next is a parser code fragment, that demonstrates how content of “linear_chain” module description is interpreted. Grouping is implemented through the concept of internal linear Z ordered chain of transport modules.
else if (_wcsicmp(geomType.c_str(), L"linear_chain") == 0)
{
t = new mcTransportLinearChain(origin, normal, xaxis);
for (auto node : geometry.Nodes)
{
if (_wcsicmp(node.Name.c_str(), L"module") == 0)
{
mcTransport* eobj = GeometryParser::ParseTransport(node, media, nThreads);
if (eobj == nullptr)
throw exception("Embedding group should contain only embedding objects");
eobj->MoveToCoordinateSystem(t->MT2W());
((mcTransportLinearChain*)t)->addTransport(eobj);
}
}
((mcTransportLinearChain*)t)->completeInit();
}
In this code example variable t represents transport module which will be inserted in to the current transport chain.
Note
Nested modules coordinate system is defined relatively to the parent module.
In this particular module “linear_chain” example demonstrates implementation accelerator head collimating structures sequence, where elements can be separated by planes, orthogonal to Z axis.


Share your interests with Us
Lorem ipsum dolor sit amet consectetur adipisicing elit. Vitae, eum?
PREFERRED COUNTRIES
BEST PLACES TO VISIT
BEST HOTELS
GREECE
SANTORONI-FIRA,OIA & VOLCANIC FEATURES
UMA RAY SUITES
ITALY
ROME-THE COLOSSEUM,IONIC ART & VATICAN
JAKITON MALLLORCA
PARIS
EIFFEL TOWER
LOUVRE MUSEUM


MCOOKIE(1) User Commands MCOOKIE(1) NAME mcookie - generate magic cookies for xauth SYNOPSIS mcookie [options] DESCRIPTION mcookie generates a 128-bit random hexadecimal number for use with the X authority system. Typical usage: xauth add :0 . `mcookie` The "random" number generated is actually the output of the MD5 message digest fed with various pieces of random information: the current time, the process id, the parent process id, and optionally the contents of an input file. and several bytes of information from the first of the fol‐ lowing devices which is present: /dev/random, /dev/urandom, files in /proc, /dev/audio. OPTIONS -f, --file=FILE Use file as a macig cookie seed. When file is defined as `-' char‐ acter input is read from stdin. -v, --verbose Explain what is being done. -V, --version Output version information and exit. -h, --help Display this help and exit. BUGS The entropy in the generated 128-bit is probably quite small (and, there‐ fore, vulnerable to attack) unless a non-pseudorandom number generator is used (e.g., /dev/random under Linux). It is assumed that none of the devices opened will block. FILES /dev/random /dev/urandom /dev/audio /proc/stat /proc/loadavg SEE ALSO X(1), xauth(1), md5sum(1) AVAILABILITY The mcookie command is part of the util-linux package and is available from ftp://ftp.kernel.org/pub/linux/utils/util-linux/. util-linux June 2011 MCOOKIE(1)


|
Contiki 2.5
|
Many StZNet API functions return an ::StStatus value to indicate the success or failure of the call. More...
Defines | |
| #define | DEFINE_ERROR(symbol, value) ST_ ## symbol = value, |
| Macro used by error-def.h to define all of the return codes. | |
Enumerations | |
| enum | { ST_ERROR_CODE_COUNT } |
Many StZNet API functions return an ::StStatus value to indicate the success or failure of the call.
Return codes are one byte long. This page documents the possible status codes and their meanings.
See error-def.h for source code.
See also error.h for information on how the values for the return codes are built up from these definitions. The file error-def.h is separated from error.h because utilities will use this file to parse the return codes.
| #define DEFINE_ERROR | ( | symbol, | |
| value | |||
| ) | ST_ ## symbol = value, |
Macro used by error-def.h to define all of the return codes.
| symbol | The name of the constant being defined. All St returns begin with ST_. For example, ::ST_CONNECTION_OPEN. |
| value | The value of the return code. For example, 0x61. |