natgillin/translations-raw huggingface dataset:
Jmenné prostory ve službě NtS Web Service jsou založeny na webové doméně odborných skupin RIS, http://www.ris.eu/.
The namespaces in the NtS Web Service are based on the web domain of the RIS Expert Groups, http://www.ris.eu/
Jmenné prostory obsahují částici, která indikuje příslušné informace o službě a verzi.
The namespaces contain a particle indicating the corresponding service and version information.
Zde uvedená služba tudíž používá tento jmenný prostor:
Hence, the service specified here uses the following namespace:
Služba pro zprávy NtS: http://www.ris.eu/nts.ms/2.0.4.0
NtS Message Service: http://www.ris.eu/nts.ms/2.0.4.0
Pro větší transparentnost dokumentů XML se doporučuje definovat jmenné prostory v nejkrajnějším vhodném prvku ve schématech a dokumentech instance a nepoužívat místní definice jmenných prostorů ve vnořených prvcích.
For higher transparency of XML documents it is recommended to define namespaces in the outmost suitable element in the schemas as well as the instance documents and not to use local namespace definitions in nested elements.
Požadavky a odpovědi ve službě NtS Web Service musí používat prvky XML v kvalifikované formě, tzn. s výslovně zadanou předponou jmenného prostoru, a atributy XML v nekvalifikované formě, tzn. bez předpony jmenného prostoru.
Requests and responses in the NtS Web Service shall use XML elements in qualified form, i.e. with an explicit namespace prefix, and XML attributes in unqualified form, i.e. without a namespace prefix.
Za účelem lepší srozumitelnosti pro lidi se doporučuje používat intuitivní předpony jmenných prostorů, např. „nts“.
It is recommended to use intuitive namespace prefixes like ‘nts’ for better human readability.
Kód ISRS Location Code je vysvětlen v kapitole 2 příručky NtS Encoding Guide pro vývojáře aplikací a také v příručce RIS Index Encoding Guide.
The ISRS Location Code is explained in chapter 2 of the NtS Encoding Guide for application developers as well as the RIS Index Encoding Guide.
Při zadávání dotazů do služby NtS Web Service může klient odkazovat na různé objekty, např. úseky plavební dráhy, vodočty nebo plavební stupně.
Querying an NtS Web Service, the client can reference various objects, e.g. fairway sections, gauges or locks.
Pokud se použijí odpovídající parametry, tzv. identifikační prvky (id elements), musí obsahovat kódy ISRS Location Code.
If the corresponding parameters, the id elements, are used, they must contain ISRS Location Codes.
Tyto parametry se obvykle uvádějí v identifikačních prvcích (id elements), přičemž každý obsahuje jedno nebo dvě ID.
These parameters are typically given in id elements, each containing one or two ids.
Při používání těchto parametrů je nutno dodržovat následující obecné konvence:
When using these parameters, the following general conventions have to be observed:
Kódy ISRS Location Codes se musí zadávat jako kódy plné délky tvořené 20 znaky, tzn. bez vynechání koncových nul.
ISRS Location Codes have to be submitted as full-length 20-character codes, i.e. without truncating trailing zeros,
Pokud se v rámci jednoho identifikačního prvku (id element) použijí dvě ID, musí oba kódy ISRS Location Code odkazovat na tutéž vodní cestu.
If two ids are used within an id element, both ISRS Location Codes have to refer to the same waterway.
To znamená, že tyto kódy obsahují některé shodné číslice nacházející se v části kódu ISRS Location Code, který identifikuje úsek plavební dráhy (fairway_section).
This means, that the codes include some identical digits located in the fairway_section part of the ISRS Location Code.
Kód úseku plavební dráhy spolu s hektometrem plavební dráhy udává úsek vodní cesty zadaný jako dvojice identifikačních prvků (id elements).
The fairway section code together with the fairway hectometre defines a waterway stretch provided as pair of id elements.
Při specifikování úseků vodních cest (dvojic identifikačních prvků v rámci geografických informací o objektu v plavební dráze (fairway_section geo_object)) ve zprávách NtS je nutno v souvislosti s kódy ISRS Location Code vzít v úvahu následující:
For the provision of waterway stretches (id element pairs within the fairway_section geo_object) in NtS messages, the following has to be considered with respect to the ISRS Location Codes:
číslice 1 až 2 (Country code):
digits 1 to 2 (Country code):
musí být v rámci dvojice ID totožné, ale
have to be identical within the id pair, but
v rámci jedné dvojice ID lze zadat různé kódy zemí, pokud sousední země používají stejný kód úseku plavební dráhy pro určitou vodní cestu a stejný systém pro definování hektometrů,
different country codes may be defined within one id pair in case neighbouring countries are using the same fairway section code for a specific waterway and the same system for defining the hectometres,
číslice 3 až 5 (UN Location code):
digits 3 to 5 (UN Location code):
nejsou relevantní, mohou být v rámci dvojice ID rozdílné,
are not relevant, may contain different content within the id pair,
číslice 6 až 10 (Fairway section code):
digits 6 to 10 (Fairway section code):
[výjimka]: v případě použití belgických kódů ISRS ve službě NtS WS by se k identifikaci úseku plavební dráhy měly používat pouze číslice 6 až 8, protože zprávy NtS budou zveřejňovány v různých úsecích v rámci jedné plavební dráhy,
[exception]: in case of using the Belgian ISRS codes within NtS WS, one should use only digits 6 to 8 to identify the fairway section, because NtS messages will be published across different sections within one fairway,
číslice 11 až 15 (Object Reference code):
digits 11 to 15 (Object Reference Code).
číslice 16 až 20 (Fairway Hectometre):
digits 16 to 20 (Fairway Hectometre):
jsou tvořeny pěticí číslic, které udávají hektometr, a tudíž budou obvykle v rámci dvojice ID rozdílné.
consist of five numerical digits defining the hectometre thus will usually contain different content within the id pair.
Příklad: „00235“ znamená kilometr 23,5 plavební dráhy, zatímco „00001“ znamená kilometr 0,1 plavební dráhy,
Example: ‘00235’ for fairway km 23,5; ‘00001’ for fairway km 0,1,
[výjimka]: v případě Nizozemska neexistuje vždy přímá souvislost mezi hektometrem plavební dráhy a fyzickým kilometrem plavební dráhy, a to v důsledku definice začátku úseku plavební dráhy v síťovém modelu a v reálném světě.
[exception]: in case of the Netherlands there is not always a direct connection between the Fairway hectometre and the physical kilometre of the fairway due to the definition of the start of the fairway stretch in the network model and in the real world, in such cases the Object Reference Code for objects of the type ‘dismar’ starts with Kxxxx (xxxx includes the physical kilometre, e.g. NLSVG00130K000300191 (km 3)).
V takových případech referenční kód objektů typu „dismar“ začíná řetězcem Kxxxx (xxxx zahrnuje fyzický kilometr, např. NLSVG00130K000300191 (km 3)).
But for other types of objects there is no direct relation to the physical fairway km in the ISRS codes, e.g. the bridge of Sas van Gent on the same fairway at km 2,5 has the ISRS code NLSVG001300521600186.
Avšak u jiných typů objektů neexistuje v kódech podle ISRS žádná přímá souvislost s fyzickým kilometrem plavební dráhy, např. most Sas van Gent na stejné plavební dráze na km 2,5 má kód podle ISRS NLSVG001300521600186.
For the Kanaal Gent-Terneuzen the physical km 0,0 starts at the border of Belgium and the Netherlands and the Fairway Hectometre 0,0 starts at the beginning of the canal in Gent.
V případě kanálu Kanaal Gent-Terneuzen začíná fyzický kilometr 0,0 na hranicích Belgie a Nizozemska a hektometr 0,0 plavební dráhy začíná na začátku kanálu v Gentu.
In case a message touches more than one waterway or fairway sections all fairway sections have to be defined by their begin- and end-point in separate ‘fairway_section’ XML elements.
Pokud se zpráva týká více než jednoho úseku vodní cesty nebo plavební dráhy, musí být všechny úseky plavební dráhy vymezeny svým počátečním a koncovým bodem v samostatných prvcích XML „fairway_section“.
For some countries/regions it is required to build filter functionality.
Pro některé země nebo regiony se vyžaduje vytvoření filtrovací funkce.
For example if ISRS Location Code (1-2) is BE use ISRS Location Code (6-8) as the ID for linear referencing with the fairway hectometre (ISRS Location Code 16-20).
Například pokud kód ISRS Location Code (1-2) je BE, použijte kód ISRS Location Code (6-8) jako ID pro lineární odkazování s hektometrem plavební dráhy (ISRS Location Code 16-20).
Examples for fairway stretches (valid id element pairs within the fairway_section) that include above defined exceptions:
Příklady pro úseky plavební dráhy (platné dvojice ID prvků v fairway_section), které obsahují výše uvedené výjimky:
The two NL ISRS Location Codes are a valid definition of a waterway stretch (showing NL exception with respect to the kilometre of the fairway): NLSVG00130K000300191 (km 3,0 at Sas van Gent on the Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 at Westdorpe on the Kanaal Gent-Terneuzen),
Dva nizozemské kódy ISRS Location Code jsou platnou definicí úseku vodní cesty (ilustrující nizozemskou výjimku, pokud jde o kilometr plavební dráhy): NLSVG00130K000300191 (kilometr 3,0 v místě Sas van Gent na kanálu Kanaal Gent-Terneuzen) – NLWDP00130K000400200 (kilometr 4,0 v místě Westdorpe na kanálu Kanaal Gent-Terneuzen),
The two BE ISRS Location Codes are a valid definition of a waterway stretch (showing BE exception with respect to the fairway section code (‘020’ Albertkanaal)): BEGNK02016L010100414 (lock of Genk located at km 41,4 on the Albert Canal) — BEOSH02033L010500772 (lock of Ham located at km 77,2 on the Albert Canal).
Dva belgické kódy ISRS Location Codes jsou platnou definicí úseku vodní cesty (ilustrující belgickou výjimku, pokud jde o kód úseku plavební dráhy („020“ Albertkanaal)): BEGNK02016L010100414 (plavební stupeň Genk na kilometru 41,4 kanálu Albert Canal) – BEOSH02033L010500772 (plavební stupeň Ham na kilometru 77,2 na kanálu Albert Canal).
The following figure shows counter-examples of ISRS Location Code usage for each of the general conventions (no exceptions to the general conventions apply to SK waterway stretches):
Následující obrázek ukazuje protikladné příklady použití kódu ISRS Location Code pro každou z obecných konvencí (na úseky slovenských vodních cest se žádné výjimky z obecných konvencí nevztahují):
Invalid ISRS Location Code queries
Neplatné dotazy pomocí kódů ISRS Location Code
General remark: A service to query valid ISRS Location Codes is not supported by the NtS Web Service.
Obecná poznámka: Služba NtS Web Service neumožňuje dotazy na platné kódy ISRS Location Code.
The ISRS Location Codes are provided within the European Reference Data Management System (ERDMS).
Kódy ISRS Location Code jsou uvedeny v Evropském systému pro správu referenčních údajů (ERDMS).
The correct usage of ISRS Location Codes in queries and their interpretation is given in the following five cases.
Následujících pět případů uvádí příklady správného použití kódů ISRS Location Code v dotazech a jejich interpretaci.
Case 1: No ids element in request
Případ č. 1: Požadavek neobsahuje žádný prvek ids
The ids element is an optional part of the request, i.e. a query without any ids elements is allowed:
Prvek ids je nepovinnou součástí požadavku, takže lze zadat i dotaz bez jakýchkoli prvků ids:
Valid query without ids parameter
Platný dotaz bez parametru ids
If no ids element is given, all messages shall be returned (depending, of course, on other filter criteria like validity_period or dates_issue).
Pokud není zadán prvek ids, vrátí se – samozřejmě v závislosti na dalších filtrovacích kritériích, jako je doba platnosti (validity_period) nebo datum vydání zprávy (date_issue) – všechny zprávy.
Case 2: One id element in request
Případ č. 2: Požadavek obsahuje jeden prvek id
Each ids element can contain one or two id elements.
Každý prvek ids může obsahovat jeden nebo dva prvky id.
The case of one id element is shown in the following figure:
Následující obrázek ukazuje případ, kdy dotaz obsahuje jeden prvek id:
Valid query with one id parameter
Platný dotaz s jedním parametrem id
If such a query is received, the server shall return all matching messages with a start hectometre ≤ the given value (240,7 in the example) and an end hectometre ≥ this value.
V případě obdržení takového dotazu server vrátí všechny odpovídající zprávy, u kterých hektometr počátečního bodu ≤ zadané hodnotě (v příkladu je to konkrétně 240,7) a hektometr koncového bodu ≥ této hodnotě.
The figure below depicts this selection of messages: The position queried lies between the start and end hectometre values of messages 1, 3 and 4, which would be returned.
Níže uvedený obrázek ukazuje následující výběr zpráv: Poloha, která je předmětem dotazu, leží mezi hektometrem počátečního bodu a hektometrem koncového bodu zpráv č. 1, 3 a 4, takže tyto zprávy by byly vráceny.
Messages 2, 5 and 6 do not overlap with the query position, so they would not be returned.
Zprávy č. 2, 5 a 6 se týkají úseků nebo objektů, jejichž poloha se nepřekrývá s polohou, která je předmětem dotazu, takže tyto zprávy by nebyly vráceny.
If the given ISRS Location Code denotes a singular object, e.g. a gauge or a lock, the web service should return the messages involving this object.
Pokud daný kód ISRS Location Code označuje jediný objekt, např. vodočet nebo plavební stupeň, webová služba (web service) by měla vrátit zprávy, které se tohoto objektu týkají.
Matching and not matching messages for one id parameter
Odpovídající a neodpovídající zprávy pro jeden parametr id
Case 3: Two id elements in request
Případ č. 3: Požadavek obsahuje dva prvky id
The case of two id elements is shown in the following figure:
Následující obrázek ukazuje případ, kdy dotaz obsahuje dva prvky id:
Valid query with two id parameters
Platný dotaz se dvěma parametry id
All hectometre values queried shall be treated as valid, even if the corresponding fairway section has different start or end points.
Všechny hodnoty v hektometrech, které jsou předmětem dotazu, budou vyhodnoceny jako platné, ačkoli odpovídající úsek plavební dráhy má odlišné body začátku a konce.
For instance, if the fairway section starts at hectometre 100,0 and ends at hectometre 300,0, a request querying hectometres 20,0 up to 400,0 would be valid.
Pokud například nějaký úsek plavební dráhy začíná na hektometru 100,0 a končí na hektometru 300,0, byl by dotaz na hektometry 20,0 až 400,0 platný.
Internally, of course, only the ‘real’ extent of the fairway section is searched.
Interně se samozřejmě vyhledává jen „skutečný“ rozsah úseku plavební dráhy.
Doing so also enables the search for all messages on a fairway without knowing its exact hectometre range (one would send its ISRS Location Code with hectometres set to ‘00000’ or ‘99999’ respectively).
To rovněž umožňuje vyhledat všechny zprávy o plavební dráze, aniž by bylo známo přesné rozmezí hektometrů (uživatel by odeslal svůj kód ISRS Location Code s hektometry nastavenými na „00000“ respektive „99999“).
All matching messages intersecting the given hectometre interval shall be returned.
Budou vráceny všechny odpovídající zprávy, které se týkají úseků nebo objektů, jejichž poloha protíná interval v hektometrech, který je předmětem dotazu.
The following diagram illustrates this situation:
Tuto situaci znázorňuje následující graf:
Matching and not matching messages for two id parameters
Odpovídající a neodpovídající zprávy pro dva parametry id
The figure above shows, how ‘intersecting’ is defined.
Výše uvedený obrázek ukazuje, jak je definováno „protnutí“.
While the extents of the messages 1 to 4 overlap with the extent of the queried hectometre range (partially or completely), the extents of messages 5 and 6 do not, therefore messages 1 to 4 will be returned, 5 and 6 will not be returned.
Zatímco rozsahy u zpráv č. 1 až 4 se (částečně nebo zcela) překrývají s rozsahem v hektometrech, který je předmětem zadaného dotazu, v případě rozsahů u zpráv č. 5 a 6 tomu tak není, a proto budou vráceny zprávy č. 1 až 4, a zprávy č. 5 a 6 vráceny nebudou.
The technical condition for a message to intersect with an interval [A, B] is: The start hectometre of the message is ≤ B and its end hectometre is ≥ A.
Kombinace: Požadavek obsahuje více prvků ids
Valid query with multiple ids elements
Platný dotaz s více prvky ids
The combination of several ids elements in the request leads to a union of the corresponding messages.
Kombinace několika prvků ids v dotazu vede ke sjednocení odpovídajících zpráv.
All the ids elements are treated individually and a message will be returned, if it matches at least one of them.
Každý z prvků ids se zpracovává jednotlivě a zpráva bude vrácena v případě, že odpovídá alespoň jednomu z nich.
Therefore, the following messages would be returned for the given example:
V uvedeném příkladu by proto byly vráceny tyto zprávy:
All messages for the object with the ISRS Location Code SKXXX0000010000***** with start hectometre =0 and end hectometre ≥ 0 (see Case 2)
všechny zprávy týkající se objektu s kódem ISRS Location Code SKXXX0000010000***** s počátečním hektometrem =0 a koncovým hektometrem ≥ 0 (viz případ č. 2),
All messages for the object with the ISRS Location Code SKXXX0000500000***** which intersect the hectometre interval [11,0, 15,0] (see Case 3) — All messages for the object with the ISRS Location Code SKXXX0000200000***** with start hectometre ≤ 110,5 and end hectometre ≥ 110,5 (see Case 2)
všechny zprávy týkající se objektu s kódem ISRS Location Code SKXXX0000500000*****, který protíná interval v hektometrech [220,0 až 300,0] (viz případ č. 3).
All messages for the object with the ISRS Location Code SKXXX0000500000***** which intersect the hectometre interval [220,0, 300,0] (see Case 3)
Tato kapitola obsahuje implementační specifikaci služby pro zprávy NtS, odvozenou od úvah a možností uvedených v předchozích kapitolách.
In this chapter the implementation specification of the NtS message service is given, deduced from the considerations and choices in the preceding chapters.
Služba pro zprávy NtS poskytuje čtyři typy zpráv NtS:
The NtS message service provides the four types of messages in the NtS:
NtS FTM (zpráva týkající se vodních cest a provozu),
NtS FTM (fairway and traffic related message)
NtS WRM (zpráva týkající se vody),
NtS WRM (water related message)
NtS ICEM (zpráva týkající se ledu),
NtS ICEM (ice message)
NtS WERM (zpráva týkající se počasí).
NtS WERM (weather related message)
Implementace služby pro zprávy NtS může podporovat všechny typy zpráv, nebo jen některé z nich.
An implementation of the NtS message service can support all message types or just a selection.
Je povoleno, aby zúčastněný členský stát poskytoval pro konkrétní typ zprávy více služeb, které se navzájem doplňují.
It is allowed that a participating Member State provides more than one service for a specific message type, that complement each other.
Aby se dosáhlo maximální robustnosti služby při co nejmenší složitosti, nepoužívá se pro službu NtS Web Service žádný další dotazovací jazyk.
In order to achieve a maximum robustness of the service while keeping the complexity on a low level no additional query language is used for the NtS Web Service.
Místo toho se používají výrazy poskytované samotným jazykem WSDL.
Instead the constructs provided by WSDL itself are applied.
Konkrétní operace spolu s jejich parametry jsou plně vymezeny v rámci specifikace WSDL.
The specific operations together with their parameters are specified entirely within the WSDL specification.
V případě služby pro zprávy NtS je definována jedna operace.
In the case of the NtS Message Service a single operation is defined.
Filtrovací kritéria specifická pro daný předmět jsou převzata z normy pro zprávy NtS, ale rozšířena, pokud jde o rozmanitost parametrů:
The subject-specific filter criteria are taken from the NtS standard, but extended concerning multiplicity of the parameters:
typ zprávy (povinné kritérium; jeden z typů „FTM“, „WRM“, „ICEM“, „WERM“),
type of message (compulsory; one of ‘FTM’, ‘WRM’, ‘ICEM’, ‘WERM’),
konkrétní úseky vodní cesty nebo jejich části nebo konkrétní objekty (nepovinné kritérium; definovány jedním kódem ISRS Location Code a/nebo dvojicemi těchto kódů),
specific waterway sections or parts thereof, or specific objects (optional; described by single ISRS Location Codes and/or pairs of ISRS Location Codes),
doba platnosti (nepovinné kritérium; datum začátku a datum konce);
time of validity (optional; start date and end date),
datum zveřejnění zprávy (nepovinné kritérium; jednotlivá data a/nebo jejich intervaly).
date of publication of the notice (optional; single dates and/or intervals of dates).
Služba vrací pouze zprávy, které odpovídají zadaným kritériím.
Only the messages matching the given criteria are returned by the service.
Mechanismus stránkování
Paging mechanism
Za účelem regulace objemu dat je podporován mechanismus stránkování.
In order to control the amount of data a paging mechanism is supported.
Stránkovací parametr je definován komplexním typem obsahujícím následující prvky:
The paging parameter is defined with a complex type containing the following elements:
offset: pořadové číslo první vrácené zprávy (celé číslo > 0),
offset: serial number of the first returned message (integer ≥ 0),
limit: max. počet zpráv (celé číslo > 0),
limit: max. number of messages (integer ≥ 0),
total count: příznak, pokud bude vrácen celkový počet zpráv (hodnota typu Boolean).
total count: flag, if total number of messages shall be returned (Boolean value).
Komplexní stránkovací parametr je volitelný, ale pokud je přítomen, musí být uvedeny všechny prvky v jeho rámci.
The complex paging parameter is optional, but if it is present, all elements within have to be given.
Potom mechanismus stránkování funguje takto:
Then, the paging mechanism works in the following way:
Celkový počet zpráv nepřekročí hodnotu parametru limit, s tou výjimkou, že hodnota 0 znamená „žádný limit“.
The total number of messages will not exceed the value of the parameter limit, with the exception that a value of 0 means ‘no limit’.
Odpověď přeskočí tolik zpráv, kolik je definováno v parametru offset.
The response skips as many messages as defined in the parameter offset.
Aby služba tento mechanismus mohla poskytovat, musí dodržovat dočasně stabilní (ale jinak libovolnou) posloupnost zpráv, např. mezi dvěma aktualizacemi dat zpráv vůči výchozímu datovému souboru webové služby (web service).
In order to provide this mechanism, the service has to observe a temporarily stable (but otherwise arbitrary) sequence of the messages, e.g. between two updates of message data on the underlying data set of the web service.
To znamená, že dvě po sobě jdoucí totožná volání musí vrátit stejné zprávy ve stejném pořadí.
This means that two consecutive identical calls must return the same messages in the same order.
Parametr total count určuje, zda odpověď poskytne celkový počet zpráv odpovídajících kritériím specifickým pro daný předmět.
The parameter total count determines whether the response shall provide the total number of messages matching the subject-specific criteria.
Obvykle by mělo stačit vyžádat si tuto informaci s první odpovědí, ale vynechat ji ve všech následných odpovědích.
Usually it should be sufficient to request this information with the first response, but omit it in all consecutive responses.
Výsledkem by byl lepší výkon webové služby.
This should result in a better performance of the web service.
Mechanismus stránkování představuje způsob, jak si zprávy vyžádat iterativně, po jednotlivých „stránkách“.
The paging mechanism provides a means to request the messages iteratively in ‘pages’.
Aby mechanismus stránkování správně fungoval, musí být v každém volání poskytnuty stejné parametry specifické pro daný předmět.
In order for the paging mechanism to work properly, the same subject-specific parameters have to be provided in each call.
V případě úspěšného požadavku obsahuje odpověď služby NtS Web Service zprávy NtS, které odpovídají parametrům požadavku.
In case of a successful request the NtS Web Service response contains the NtS messages that match the request parameters.