natgillin/translations-raw huggingface dataset:
За представянето на участъци от водни пътища (двойки идентификационни елементите във fairway_section на geo_object) в NtS съобщенията трябва да се има предвид следното във връзка с ISRS Location Codes:
[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)).
1 до 2 символа (Country code):
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.
трябва да са идентични в рамките на идентификационната двойка, но
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.
в рамките на една идентификационна двойка могат да бъдат определени различни кодове на държави, ако съседни държави използват един и същи код за даден участък от фарватера за конкретен воден път и една и съща система за определяне на хектометрите,
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.
3 до 5 символа (UN Location code):
For some countries/regions it is required to build filter functionality.
не са релевантни, възможно е съдържанието в рамките на идентификационната двойка да е различно,
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).
6 до 10 символа (Fairway section code):
Examples for fairway stretches (valid id element pairs within the fairway_section) that include above defined exceptions:
[изключение]: ако в NtS WS се използват белгийските ISRS кодове, за идентифицирането на участъка от фарватера следва да се използват само 6 до 8 символа, тъй като NtS съобщенията ще бъдат публикувани в различни участъци в рамките на един фарватер,
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),
11 до 15 символа (Object Reference Code).
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).
16 до 20 символа (Fairway Hectometre):
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):
състои се от 5 цифрови символа за определяне на хектометъра, като така съдържанието в рамките на идентификационната двойка обикновено е различно.
Invalid ISRS Location Code queries
Пример: „00235“ за 23,5-ия km от фарватера; „00001“ за 0,1-ия km от фарватера,
General remark: A service to query valid ISRS Location Codes is not supported by the NtS Web Service.
[изключение]: когато става дума за Нидерландия, невинаги има пряка връзка между хектометъра на фарватера и физическия километър, тъй като началото на участъка от фарватера се определя в мрежовия модел и в реалността, като в такива случаи Object Reference Code за обекти от вида „dismar“ започва с Kxxxx (хххх включва физическия километър, напр.
The ISRS Location Codes are provided within the European Reference Data Management System (ERDMS).
NLSVG00130K000300191 (km 3).
The correct usage of ISRS Location Codes in queries and their interpretation is given in the following five cases.
За други видове обекти обаче в ISRS кодовете не се съдържа пряка връзка с физическия километър, напр.
Case 1: No ids element in request
ISRS кодовете на моста на Sas van Gent на 2,5-ия km от един и същи фарватер е NLSVG001300521600186.
The ids element is an optional part of the request, i.e. a query without any ids elements is allowed:
За Kanaal Gent-Terneuzen физическият километър 0,0 започва на границата между Белгия и Нидерландия, а хектометърът на фарватера 0,0 започва в началото на канала в Гент.
Valid query without ids parameter
В случай че дадено съобщение касае повече от един участък от водния път или фарватера, всички участъци от фарватера трябва да бъдат определени спрямо тяхната начална и крайна точка в отделни XML елементи на „участъка от фарватера“.
If no ids element is given, all messages shall be returned (depending, of course, on other filter criteria like validity_period or dates_issue).
За някои държави/региони има изискване за разработване на филтрираща функция.
Case 2: One id element in request
Например ако ISRS Location Code (1-2) е BE, използвайте ISRS Location Code (6-8) като ID за линейно отправяне към хектометъра на фарватера (ISRS Location Code 16-20).
Each ids element can contain one or two id elements.
Примери за участъци от фарватера (валидни двойки идентификационни елементи в рамките на участъка от фарватера), които включват описаните по-горе изключения:
The case of one id element is shown in the following figure:
Двата нидерландски ISRS Location Codes валидно определят участък от водния път (пример с изключението за Нидерландия по отношение на фарватер-километъра): NLSVG00130K000300191 (3,0-ия km при Sas van Gent на Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (4,0-ия km при Westdorpe на Kanaal Gent-Terneuzen),
Valid query with one id parameter
Двата белгийски ISRS Location Codes валидно определят участък от водния път (пример с изключението за Белгия по отношение на кода за участък от фарватера („020“ Albertkanaal): BEGNK02016L010100414 (шлюз Genk, разположен на 41,4-ия km от Albert Canal) — BEOSH02033L010500772 (шлюз Ham, разположен на 77,2-ия km от Albert Canal).
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.
На следващата фигура са дадени обратни примери за използване на ISRS Location Code за всяка от общоприетите практики (по словашките участъци от водния път не се прилагат изключенията от общоприетите практики):
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.
Невалидни заявки за ISRS Location Code
Messages 2, 5 and 6 do not overlap with the query position, so they would not be returned.
Общи забележки: Услугата за валидна заявка за ISRS Location Codes не се поддържа от NtS Web Service.
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.
ISRS Location Codes се предоставят в рамките на Европейската система за управление на справочни данни (ERDMS).
Matching and not matching messages for one id parameter
Правилното използване на ISRS Location Codes в заявките и тяхното тълкуване са представени в следните пет случая.
Case 3: Two id elements in request
Случай 1: В заявката липсват идентификационни елементи
The case of two id elements is shown in the following figure:
Идентификационните елементи са незадължителна част от заявката, т.е. заявка без нито един идентификационен елемент е допустима:
Valid query with two id parameters
Валидна заявка без идентификационен параметър
All hectometre values queried shall be treated as valid, even if the corresponding fairway section has different start or end points.
Ако не е зададен идентификационен елемент, се връщат всички съобщения (разбира се, в зависимост от други филтриращи критерии като validity_period или dates_issue).
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.
Случай 2: Един идентификационен елемент в заявката
Internally, of course, only the ‘real’ extent of the fairway section is searched.
Всеки идентификационен елемент може да съдържа един или два идентификационни елемента.
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).
Пример с един идентификационен елемент е показан на следващата фигура:
All matching messages intersecting the given hectometre interval shall be returned.
Валидна заявка с един идентификационен параметър
The following diagram illustrates this situation:
При получаване на такава заявка сървърът връща всички съобщения, при които е отчетено съвпадение, с начален хектометър ≤ на дадената стойност (240,7 в примера) и краен хектометър ≥ на тази стойност.
Matching and not matching messages for two id parameters
На фигурата по-долу е показан този избор на съобщения: търсеното място се намира между началните и крайните стойности на хектометър в съобщения 1, 3 и 4, които ще бъдат върнати.
The figure above shows, how ‘intersecting’ is defined.
При съобщения 2, 5 и 6 няма съвпадение с търсеното място, следователно те няма да бъдат върнати.
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.
Ако даден ISRS Location Code указва единичен обект, напр. водомерна станция или шлюз, web service следва да върне съобщенията, засягащи този обект.
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.
Съобщения, при които е отчетено съвпадение и съобщения, при които не е отчетено съвпадение за един идентификационен параметър
Combination: Multiple ids elements in request
Случай 3: Два идентификационни елемента в заявката
Valid query with multiple ids elements
Пример с два идентификационни елемента е показан на следващата фигура:
The combination of several ids elements in the request leads to a union of the corresponding messages.
Валидна заявка с два идентификационни параметъра
All the ids elements are treated individually and a message will be returned, if it matches at least one of them.
Всички търсени хектометрични стойности се третират като валидни дори ако съответният участък от фарватера има различни начални и крайни точки.
Therefore, the following messages would be returned for the given example:
Например, ако участъкът от фарватера започва при хектометър 100,0 и свършва при хектометър 300,0, заявка за хектометри 20,0—400,0 ще бъде валидна.
All messages for the object with the ISRS Location Code SKXXX0000010000***** with start hectometre =0 and end hectometre ≥ 0 (see Case 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)
Това позволява също така търсенето да обхване всички съобщения за даден фарватер без да се знае неговият точен хектометричен диапазон (ISRS Location Code може да се изпрати с хектометри, зададени съответно на „00000“ или „99999“).
All messages for the object with the ISRS Location Code SKXXX0000500000***** which intersect the hectometre interval [220,0, 300,0] (see Case 3)
Връщат се всички съобщения, при които е отчетено съвпадение и които се припокриват с дадения хектометричен интервал.
In this chapter the implementation specification of the NtS message service is given, deduced from the considerations and choices in the preceding chapters.
Това положение е представено на следната диаграма:
The NtS message service provides the four types of messages in the NtS:
Съобщения, при които е отчетено съвпадение и съобщения, при които не е отчетено съвпадение за два идентификационни параметъра
NtS FTM (fairway and traffic related message)
Фигурата по-горе показва как се определя „припокриването“.
NtS WRM (water related message)
Докато обхватът на съобщения 1 до 4 се припокрива с обхвата на търсения хектометричен диапазон (частично или напълно), при съобщения 5 и 6 това не е така, следователно съобщения 1 до 4 ще бъдат върнати, а 5 и 6 няма да бъдат върнати.
NtS ICEM (ice message)
Техническата предпоставка за припокриване на дадено съобщение с определен интервал [A, B] е: Началният хектометър на съобщението да е ≤ B, а крайният хектометър да е ≥ A.
NtS WERM (weather related message)
Комбинация: Множество идентификационни елементи в заявката
An implementation of the NtS message service can support all message types or just a selection.
Валидни заявки с множество идентификационни елементи
It is allowed that a participating Member State provides more than one service for a specific message type, that complement each other.
Съчетаването на няколко идентификационни елемента в заявката води до обединяване на съответните съобщения.
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.
Всички идентификационни елементи се обработват поотделно, като съобщение се връща при отчитане на съвпадение с поне един от тях.
Instead the constructs provided by WSDL itself are applied.
Следователно в дадения пример ще бъдат върнати следните съобщения:
The specific operations together with their parameters are specified entirely within the WSDL specification.
Всички съобщения за обекта с Location Code SKXXX0000010000***** с начален хектометър =0 и краен хектометър ≥ 0 (вж. случай 2) — Всички съобщения за обекта с ISRS Location Code SKXXX0000500000*****, които се припокриват с хектометричния интервал [11,0, 15,0] (вж. случай 3)
In the case of the NtS Message Service a single operation is defined.
Всички съобщения за обекта с ISRS Location Code SKXXX0000200000***** с начален хектометър =110,5 и краен хектометър ≥ 110,5 (вж. случай 2)
The subject-specific filter criteria are taken from the NtS standard, but extended concerning multiplicity of the parameters:
Всички съобщения за обекта с ISRS Location Code SKXXX0000500000*****, които се припокриват с хектометричния интервал [220,0, 300,0] (вж. случай 3)
type of message (compulsory; one of ‘FTM’, ‘WRM’, ‘ICEM’, ‘WERM’),
В настоящата глава са дадени спецификациите за изпълнение на услугата за NtS съобщения, изведени от съображенията и изборите в предишните глави.
specific waterway sections or parts thereof, or specific objects (optional; described by single ISRS Location Codes and/or pairs of ISRS Location Codes),
Услугата за NtS съобщения предоставя четирите вида съобщения в NtS:
time of validity (optional; start date and end date),
NtS FTM (съобщение за фарватера и трафика)
date of publication of the notice (optional; single dates and/or intervals of dates).
NtS WRM (съобщение за нивото на водата)
Only the messages matching the given criteria are returned by the service.
NtS WRM (съобщение за ледови явления)
Paging mechanism
NtS WERM (съобщение за метеорологичната обстановка)
In order to control the amount of data a paging mechanism is supported.
Изпълнението на услугата за NtS съобщения може да поддържа всички видове съобщения или само избрана част от тях.
The paging parameter is defined with a complex type containing the following elements:
Допуска се участваща държава членка да предоставя повече от една услуга за конкретен вид съобщение, като тези услуги може да се допълват взаимно.
offset: serial number of the first returned message (integer ≥ 0),
С цел да се постигне максимална надеждност на услугата и в същото време нивото на сложност да остане ниско, за NtS Web Service не се използва допълнителен език за заявка.
limit: max. number of messages (integer ≥ 0),
Вместо това се дават предоставените от WSDL конструкции.
total count: flag, if total number of messages shall be returned (Boolean value).
Конкретните операции и техните параметри са уточнени изцяло в WSDL спецификациите.
The complex paging parameter is optional, but if it is present, all elements within have to be given.
За услугата за NtS съобщения е определена само една операция.
Then, the paging mechanism works in the following way:
Тематичноспецифичните филтриращи критерии се вземат от стандарта за NtS, но се разширяват в зависимост от разновидностите на параметрите:
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’.
вид на съобщението (задължителен; един от следните: „FTM“, „WRM“, „ICEM“, „WERM“)
The response skips as many messages as defined in the parameter offset.
конкретни участъци от водния път или части от него, или конкретни обекти (по избор; описани с единични ISRS Location Codes и/или двойки ISRS Location Codes)
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.
срок на валидност (по избор; начална и крайна дата)
This means that two consecutive identical calls must return the same messages in the same order.
дата на публикуване на известието (по избор; отделни дати и/или времеви интервали)
The parameter total count determines whether the response shall provide the total number of messages matching the subject-specific criteria.
Услугата връща само съобщенията, при които е отчетено съвпадение с определени критерии.
Usually it should be sufficient to request this information with the first response, but omit it in all consecutive responses.
Механизъм за номериране
This should result in a better performance of the web service.
Поддържа се механизъм за номериране, чиято цел е да се контролира обемът на данните.
The paging mechanism provides a means to request the messages iteratively in ‘pages’.
Параметърът за номериране се определя със сложен вид, съдържащ следните елементи:
In order for the paging mechanism to work properly, the same subject-specific parameters have to be provided in each call.
offset: сериен номер на първото върнато съобщение (integer ≥ 0)
In case of a successful request the NtS Web Service response contains the NtS messages that match the request parameters.
limit: макс. брой съобщения (integer ≥ 0)
The NtS messages have to comply with the NtS schema and can be validated against that schema.
total count: флаг, при необходимост от връщане на общ брой съобщения (стойност Boolean)
Since the message type is a compulsory request parameter, each response can contain only NtS messages of the same message type, FTM, WRM, ICEM or WERM respectively.
Комплексният параметър за номериране е опционален, но ако го има, всички елементи в него задължително трябва да са дадени.
If the service detects errors while processing the request it can return an arbitrary number of error messages, using the error codes listed in the following subchapter.
След това механизмът за номериране работи по следния начин:
One response of an NtS Web Service can contain NtS messages and error messages at the same time.
Общият брой съобщения не надвишава стойността на параметъра limit, с изключение на това, че стойност 0 означава „без ограничение“.
Optional paging information is returned if the request contained paging parameters.
Отговорът пропуска толкова съобщения, колкото са определени в параметър offset.
In this case the offset and number of contained messages are mandatory, the total count needs only be present if it has been requested.
За да предложи този механизъм, услугата трябва да наблюдава временно стабилна (но иначе произволна) последователност от съобщения, напр. между две актуализации на данните от съобщения в основния набор от данни на web service.
Please note: It is assumed that the communication between the web service and the user is technically established, i.e. the service receives the request and the user receives the corresponding response.
Това означава, че две последователни идентични позивни трябва да върнат едни и същи съобщения в една и съща последователност.
Technical errors, e.g. breakdown of the internet connection or inaccessibility of the web service due to maintenance or crash, are not considered here.
Параметърът total count определя дали отговорът ще съдържа общия брой съобщения, при които е отчетено съвпадение с тематичноспецифичните критерии.
Only error situations that happen ‘behind’ the web service layer from the users point of view are considered here.
Обикновено следва да е достатъчно тази информация да се поиска с първия отговор, като се пропусне във всички следващи отговори.
Error messages
Това ще доведе до подобряване на работата на web service.
The error codes for the expected error situations are given below, together with an explanation.
Механизмът за номериране е средство, позволяващо съобщенията да се заявяват повторно по „страници“.
Only the error code is contained in the response, which is the usual procedure in the XML schema of the NtS.
За да може механизмът за номериране да работи правилно, във всяка заявка трябва да се предоставят едни и същи тематичноспецифични параметри.
Error codes for the NtS message service
При успешна заявка отговорът на NtS Web Service съдържа NtS съобщенията, при които е отчетено съвпадение с параметрите на заявката.
If the contract-first approach is consequently observed, i.e. one or more contracts with complete descriptions of the interfaces are given in the form of WSDL documents, an implementation of the service(s) as well as an implementation of a corresponding client can be automatically generated using appropriate software tools.
NtS съобщенията трябва да съответстват на схемата на NtS и могат да бъдат валидирани спрямо нея.
In an ideal situation no manual changes have to be made in the generated source code.
Тъй като видът на съобщението е задължителен параметър на заявката, всеки отговор може да съдържа само NtS съобщения от същия вид, съответно FTM, WRM, ICEM или WERM.
However, in most cases several iterations are necessary until the WSDL specification meets the precise requirements of such a tool.
Ако услугата открие грешки при обработката на заявката, тя може да върне произволен брой съобщения за грешки, като използва изброените в следващата подглава кодове за грешки.
Typically the tool makes individual demands on the use of the WSDL standard in order to work smoothly.
Един отговор на NtS Web Service може да съдържа едновременно NtS съобщения и съобщения за грешки.
As a consequence changes to the WSDL specification may be necessary, although the WSDL specification was a valid specification according to the WSDL standard in the first place.
Незадължителна номерираща информация се връща, ако заявката съдържа свързани с нея параметри.
If the WSDL specification of the web service is changed after the service or the client have been generated, a new generation process may be necessary, depending on the changes made.
В този случай серийният номер на първото върнато съобщение и броят на включените съобщения са задължителни, докато общият брой трябва да се представи само при поискване.
Term
Забележка: Предполага се, че комуникацията между web service и ползвателя е технически установена, т.е. услугата получава заявката, а потребителят получава съответния отговор.
Explanation
Тук не се разглеждат въпроси, свързани с техническите грешки, напр. прекъсване на интернет връзката или недостъпност на web service, поради поддръжка или авариен отказ на системата.
Identification
Разгледани са само грешките, които се случват „отвъд“ повърхността на web service от гледна точка на потребителите.
Simple Object Access Protocol; network protocol typically used for web services
Съобщения за грешка
Universal Description, Discovery and Integration; Standard for registry services in the context of web services