KR101187537B1 - Method of managing data for real time u-portal map service - Google Patents
Method of managing data for real time u-portal map service Download PDFInfo
- Publication number
- KR101187537B1 KR101187537B1 KR1020110084871A KR20110084871A KR101187537B1 KR 101187537 B1 KR101187537 B1 KR 101187537B1 KR 1020110084871 A KR1020110084871 A KR 1020110084871A KR 20110084871 A KR20110084871 A KR 20110084871A KR 101187537 B1 KR101187537 B1 KR 101187537B1
- Authority
- KR
- South Korea
- Prior art keywords
- data
- portal map
- memory
- portal
- index
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
- G06T17/05—Geographic models
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
- G06T15/005—General purpose rendering architectures
Abstract
Description
본 발명은 실시간 U포털 지도서비스를 위한 데이터 처리방법에 관한 것이다.
The present invention relates to a data processing method for a real-time U portal map service.
본발명은 실시간으로 처리되는 U포털 지도서비스에 관한 것이다. U포털 지도서비스는 지리정보 시스템을 말하는 것으로서 지리공간 데이터를 분석가공하여 토지, 교통, 통신등과 같은 지형관련 분야에 활용하는 시스템을 가리킨다. 최근에는 네이버,다음, 구글과 같은 포털에서 지도 뿐 만 아니라 위성사진과 데이터를 제공하는 서비스를 하고 있는데 이들 포털에서 웹을 통하여 제공되는 서비스는 U포털 지도데이터를 실시간으로 그려서 제공하는 것이 아니라 이미지 형태로 저장되어 있는 데이터를 제공하게 되어 주어진 정보이외에는 변경관리가 불가능하다. 표시해야 하는 지도의 면적이 큰 경우를 위해서 지도를 몇 개의 블록으로 나누어 블록별로 데이터를 표시하는 방법을 취하고 있지만 이것역시 단순히 작은 크기의 이미지를 여러 개 가져오는 것에 불과한 것으로서 표시해야 되는 이미지가 커지거나 표시하는 매체(PC,모바일)의 메모리크기와 CPU의 영향을 받아 표시에 시간이 걸리게 된다. 즉, 각각의 표시기기마다 사용할 수 있는 메모리 공간에는 제약이 있을 수 밖에 없다. 특히 32bit운영체제를 사용하는 경우 제한된 메모리양을 사용할 수밖에 없으며 그보다 이전세대의CPU를 사용하는 경우 그 제약은 더 커지며 모바일 기기의 경우에는 사용가능한 메모리의 크기가 최대48Mbytes이하인 경우가 많아 U포털 지도데이터를 처리하는데 어려움이 크다.
The present invention relates to a U portal map service that is processed in real time. The U-Portal Map Service refers to a geographic information system. It refers to a system that analyzes and processes geospatial data and uses it in terrain-related fields such as land, transportation, and communication. Recently, portals such as Naver, Daum, and Google provide satellite photographs and data as well as maps. The services provided through the web in these portals do not draw and provide U-Portal map data in real time. It provides data that is stored as, so change management is impossible except for given information. In order to display a large area of the map that needs to be displayed, the map is divided into several blocks and data is displayed for each block. However, this is only a simple import of several small images, which increases the size of the image to be displayed. Depending on the memory size and CPU of the display medium (PC, mobile), the display takes time. That is, there is a limitation in the memory space that can be used for each display device. In particular, if you use 32bit operating system, you have to use a limited amount of memory, and if you use CPU of previous generation, the limit is bigger.In case of mobile devices, the available memory size is max. 48Mbytes or less. Difficult to deal with
도1은 통상의 U포털 지도데이터중 벡터구조데이터를 보여주는데 U포털 지도데이터는 벡터구조(공간정보와 속성정보로 구성)혹은 레스터구조를 갖는데 웹에서 서비스되는 것은 래스터구조의 U포털 지도데이터다. 도2는 벡터구조와 레스터구조의 일예를 도시한다.
FIG. 1 shows vector structure data among general U portal map data. The U portal map data has a vector structure (consisting of spatial information and attribute information) or a raster structure. What is serviced on the web is U portal map data of a raster structure. 2 shows an example of a vector structure and a raster structure.
벡터구조는 U포털 지도데이터에 변경이 생기는 경우 속성정보와 공간정보를 변경함으로써 변경된 사항을 쉽게 반영할 수 있지만 레스터구조는 데이터에 변경이 있는 경우 블록단위의 데이터를 전부 바꾸어야 하기 때문에 변경된 사항의 반영이 어려웠다. The vector structure can easily reflect the change by changing the attribute information and spatial information when the U portal map data changes, but the raster structure reflects the changed data because all data in the block unit must be changed when there is a change in the data. This was difficult.
대한민국 특허등록번호 제10-0707296호 '지리정보서비스 시스템 및 방법'은 GPS좌표정보를 사용자의 네비게이션 단말기에 제공하는 방법을 제공하고 있으나 기본적으로 지리정보를 제공하는 방법은 레스터구조에 의하고 있기 때문에 모바일등에서 적용하기 어려운 단점이 있었다
Korean Patent Registration No. 10-0707296 'Geographic Information Service System and Method' provides a method of providing GPS coordinate information to a user's navigation terminal, but basically the method of providing geographic information is based on the Leicester structure. There was a disadvantage that is difficult to apply in the back
본 발명은 상기한 바와 같은 단점을 극복하기 위하여 실시간으로 U포털 지도데이터를 처리하는 방법을 제공하는 것을 목적으로 한다.
An object of the present invention is to provide a method for processing U-portal map data in real time in order to overcome the disadvantages described above.
본 발명은 포털에서 제공되는 일방적인 웹서비스보다는 소규모 그룹에서 데이터를 공유하고 관리하며 필요에 따라 사용자가 데이터를 편집가공 및 관리한 후에 이를 반영하여 제공할 수 있도록 블럭을 실시간으로 그려내는 시스템을 목적으로 한다.
The present invention aims at a system that shares and manages data in a small group rather than a unidirectional web service provided by a portal, and draws blocks in real time so that the user can reflect and provide data after editing, processing, and managing the data as necessary. It is done.
상기한 바와 같은 목적을 달성하기 위하여 실시간 U포털 지도서비스를 위한 데이터 처리방법을 제공하는 상기 방법은, 메모리 영역은 인덱스를 저장하는 리스트그룹과 U포털 지도데이터를 저장하는 데이터 그룹으로 나뉘며 로컬스토리지에는 인덱스와 U포털 지도데이터가 함께 저장되는데 In order to achieve the above object, the method for providing a data processing method for a real-time U portal map service, the memory area is divided into a list group for storing the index and a data group for storing the U portal map data, local storage Index and U portal map data are stored together.
그리려는 도면을 미리 정의된 크기의 블록으로 나누는 블록킹단계와 나누어진 블록별로 그리기를 하는 그리기단계와; 그리기 단계는 로컬스토리지의 인덱스를 참조하여 그리기영역과 만나는 곳의 인덱스를 리스트그룹에 저장하고 그리기 영역과 만나는 U포털 지도데이터를 데이터그룹에 저장하는 스왑준비단계와메모리사용율을 참조하여 사용하지 않는 인덱스를 메모리에서 제거하고 또한 사용하지 않는 U포털 지도데이터를 메모리에서 제거하는 스왑제거단계를 포함할 수 있다. A blocking step of dividing a drawing to be drawn into blocks of a predetermined size and a drawing step of drawing for each divided block; The drawing step refers to the index of local storage and stores the index where it meets the drawing area in the list group, and the swap preparation step that stores the U-portal map data that meets the drawing area in the data group and the index that is not used by referring to the memory utilization. It may include a swap removal step of removing from the memory and also removes unused U-Portal map data from the memory.
메모리 사용율이 95%이상을 넘으면 스왑제거단계를 실시하고, 메모리 사용율이 70%이하인 경우 새로운 U포털 지도데이터를 가져오는 단계를 실시하는 것을 그리기가 완료될때까지 반복한다. If the memory usage exceeds 95%, the swap removal step is performed. If the memory usage is 70% or less, the step of importing new U-Portal map data is repeated until the drawing is completed.
두 개 이상의 CPU코어를 포함하는 경우 CPU코어마다 별도의 그리작업을 실행하는 능력을 향상 시킬수 있도록 한다. If you include more than one CPU core, you can improve the ability to execute separate grieving tasks for each CPU core.
상기 블록킹단계에서 그려야할 영역의 블록중 미리 정한 개수(CPU 코어개수)만큼 리스트그룹에 우선적으로 올려 그리기 작업을 수행한다.
In the blocking step, a drawing operation is first performed on the list group by a predetermined number (the number of CPU cores) among the blocks of the area to be drawn.
상기한 바와 같은 발명에 의하여 모바일을 포함한 어떤기기에서나 실시간으로 U포털 지도데이터를 처리하는 것이 가능해지는 효과를 갖는다.
The invention as described above has the effect that it is possible to process the U portal map data in real time from any device, including mobile.
도1,2는 U포털 지도데이터의 구조를 도시하는 도면
도3내지 도7은 본 발명에 따른 일실시예를 도시하는 도면1 and 2 show the structure of the U-portal map data.
3 to 7 show an embodiment according to the present invention.
이하, 첨부한 도면을 참고로 하여 본 발명을 상세하게 설명한다. 도3은 본 발명에 따른 시스템의 일실시예를 도시하는 도면이다. 본 발명에 따른 시스템은 화면상에 그려서 표시하여야 할 도면을 확인한다. 이때 화면의 크기와 표시해야할 도면의 크기를 확인하고 전체 도면을 몇개의 블럭으로 나눈다. 이때 블럭의 수는 화면의 크기와 표시해야할 도면의 크기에 따라 달라질 수 있다. 블럭이 생성되면 쓰레드를 생성하여 CPU 별로 그려야할 도면을 할당하여 도면을 그리게 되는데 U포털 지도데이터 DB에 있는 것을 메모리로 옮겨와 블럭을 생성하게 된다.
Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. 3 illustrates one embodiment of a system in accordance with the present invention. The system according to the present invention identifies the drawings to be drawn and displayed on the screen. At this time, check the size of the screen and the size of the drawing to be displayed, and divide the entire drawing into several blocks. The number of blocks may vary depending on the size of the screen and the size of the figure to be displayed. When a block is created, a thread is created to allocate a drawing to be drawn for each CPU to draw a drawing. The U portal map data DB is moved to memory to create a block.
실시간으로 U포털 지도데이터를 그리기 위해서는 많은 리소스를 필요로 하는데 이때 CPU, 메모리, 저장공간 등을 사용하게 된다. 특히CPU에서 그리기 작업을 수행하는 단위를 쓰레드(thread)라 하며 쓰레드 하나당 CPU 코어 하나를 배당받게 된다. 멀티코어를 지원하기 위해서는 그리기 작업을 블록 단위로 나누고 이를 각각의 쓰레드로 그리기 작업을 수행하게 된다. 이때 쓰레드 갯수가 코어 갯수보다 많아지게 되면 오히려 CPU에 부담을 주게 되므로 그리기 작업자를 코어의 개수만큼 생성하여 관리하게 된다.
Drawing U-Portal map data in real time requires a lot of resources, and uses CPU, memory, and storage space. In particular, the unit that executes drawing operations on the CPU is called a thread, and one CPU core is allocated to each thread. To support multicore, the drawing task is divided into blocks, and each thread is used to draw. At this time, if the number of threads becomes larger than the number of cores, the burden is placed on the CPU. Therefore, a drawing worker is created and managed as many as the number of cores.
또한 메모리는 한정된 환경에서 사용을 하여야 하며 무작정 늘릴 수도 없으며 HDD 와같은 local storage에 용량대비 비용도 굉장히 비싸게 적용되어 이를 위하여 본 발명에서는 아이오스왑(IO Swap)을 사용하게 된다.
In addition, the memory should be used in a limited environment and can not be increased at any time, and the cost / capacity is very expensively applied to local storage such as HDD, so that the present invention uses IO Swap.
도4는 블럭처리의 예를 도시한다. 표시해야 하는 전체 화면크기를 확인하고 블럭의 위치를 계산하게 된다. 이때 화면을 몇개의 블럭으로 나눌지를 결정하는데 기기에 따라서 미리 정해진 블럭의 크기가 있을 수 있으며 몇개의 블럭을 이용하여야 화면 전체에 표시되는지를 결정하여 블럭을 생성하게 된다.
4 shows an example of block processing. It checks the total screen size to be displayed and calculates the position of the block. At this time, there may be a predetermined block size depending on the device to determine how many blocks to divide the screen, and how many blocks are used to determine whether to display the entire screen to create a block.
도5는 블럭별 그리기를 도시한다. 블럭할당이 끝나면 각각의 블럭을 쓰레드에 등록하는데 그리기 작업이 있는지를 확인하고 CPU코어가 비게 되면 U포털 지도데이터를 가져와서 블럭그리기를 하게 된다. 블럭그리기는 공지의 것이므로 자세한 설명을 생략하였다.
5 shows a block-by-block drawing. After allocating block, each block is registered in the thread. Check if there is drawing operation. If CPU core becomes empty, U portal map data is imported and block is drawn. The block drawing is well known and thus detailed description thereof has been omitted.
그리기 작업을 할 때 아이오스왑에 의해 데이터를 가져오게 되는데 도6에는 아이오스왑이 자세하게 도시된다. 그리기 영역에 대한 요청이 있는 경우 실제 데이터를 바로 액세스 하기 보다는 인덱스를 이용하여 인덱스의 리스트에 올라있는 리스트그룹이 그리기 영역과 만나는지를 확인하고 인덱스에 따른 데이터 그룹도 그리기 영역과 만나는 지를 검사하여 맞다면 이 데이터를 query결과에 추가하고 모든데이터를 조사하게 된다.
When drawing, the data is imported by the IOS swap. FIG. 6 shows the IOS swap in detail. If there is a request for a drawing area, rather than accessing the actual data immediately, the index is used to check whether the list group in the index list meets the drawing area, and if the data group according to the index also meets the drawing area. Add this data to the query result and examine all the data.
도6은 실제그리기 과정을 도시하는데 메모리 사용율이 70%이상이라면 메모리 사용율이 95%이상인지를 확인하여 query 결과에 있는 인덱스중 사용하지 않는 인덱스를 메모리에서 제거 하고 그에따라 사용하지 않는 U포털 지도데이터도 메모리에서 제거하게 된다. 메모리 사용율이 95%이하라고 하더라도 메모리 사용율이 70%이상이라면 사용하지 않는 U포털 지도데이터를 메모리에서 제거하고 U포털 지도데이터를 가져오게 되며 이러한 작업은 그리기를 완료할때까지 반복된다.
Fig. 6 shows the actual drawing process. If the memory usage is 70% or more, the memory usage is 95% or more, and the unused indexes of the indexes in the query result are removed from the memory and the U-port map data is not used accordingly. It will also be removed from memory. Even if the memory usage is less than 95%, if the memory utilization is more than 70%, the unused U-Portal map data is removed from the memory and the U-Portal map data is imported. This operation is repeated until the drawing is completed.
즉, 어떤 영역을 그릴 것인가를 인덱스를 통하여 확인하고 실제 그리기 작업에서는 메모리 사용율에 따라 그리기를 시작하게 되며 메모리 사용율이 일정이하로(약70%)떨어지게 되면 U포털 지도데이터를 가져오게 된다.
In other words, it checks which area to draw through the index and starts drawing according to the memory usage in the actual drawing. If the memory usage falls below a certain level (about 70%), the U-port map data is imported.
도7은 아이오스왑을 위한 메모리구조를 도시한다. 로컬 스토리지에 U포털 지도데이터는 인덱스파일과 함께 저장이 되어 있으며 메모리에는 인덱스를 저장하기 위한 리스트그룹과 U포털 지도데이터를 저장하기 위한 데이터그룹으로 나뉜다. 모든 데이터를 메모리에 올리는 대신에 올릴수 있는 만큼만 메모리에 저재하고 나머지는 로컬 저장공간에 두게 되는데 그리기 영역과 만나는 데이터의 인덱스를 리스트그룹에 두고 데이터그룹은 그리기영역과 만나는 부분을 올릴 수 있는 만큼 올리게 되는데 실제 그리기 작업중에 메모리 사용율이 일정이상을 넘어가게 되면 사용하지 않는 U포털 지도데이터를 메모리에서 제거하고 리스트그룹을 참조하여 다른 U포털 지도데이터를 가져오게 되면 그리기작업에서 U포털 지도데이터를 사용하는 것이 끝날 때까지 사용하게 된다.
7 shows a memory structure for an IOS swap. The U portal map data is stored in the local storage together with the index file. The memory is divided into a list group for storing the index and a data group for storing the U portal map data. Instead of putting all the data in memory, it stores only as much as possible in memory and the rest in local storage. The index of the data that meets the drawing area is placed in the list group, and the data group is raised as much as the area that meets the drawing area. If the memory usage exceeds a certain amount during the actual drawing, remove the unused U-Portal map data from the memory and import other U-Portal map data by referring to the list group. It will be used until the end.
아이오스왑에서 잦은 데이터의 입출력을 피하기 위하여 최초 블록을 생성할 때 표시화면크기와 겹치는 블록의 면적을 계산하고 이들 블록의 데이터를 겹치는 면적의 크기순으로 배열하여 그리기인덱스리스트를 만들고 메모리가 허용하는 한도내에서 겹치는 면적이 큰 순서대로 해당 U포털 지도데이터를 올린다. 이때 그리기 인덱스리스트에는 가장 큰 몇 개만 올릴수 있는데 가장 면적이 큰 몇 개를 제외하고는 나머지의 작업순서는 어느것을 먼저하더라도 크게 문제가 없기 때문이다. 도4에서는 가운데의 블록의 크기가 가장 크기 때문에 중간의 블록데이터가 맨 위쪽에 올라오게 되어 해당 블록부터 그리기를 시작하게 되며 해당블록의 그리기가 끝나서 해당데이터를 사용하지 않게 되면 리스트그룹과 데이터그룹에서 해당 인덱스와 데이터를 삭제하고 그다음의 U포털 지도데이터를 가져오게 된다. 리스트그룹에 인덱스를 전부 올리지 않고 일부만 올리게 되면 처음에는 면적이 큰 순서대로 작업이 진행되는데 이후에는 도5와 같이 진행된다. 통상은 가장 가운데의 영역을 중심으로 그 주위의 지도를 그리게 되며 그리기 작업이 많은것부터 할당되며 그리기 작업이 많은 것부터 적은 것 순으로 진행된다. In order to avoid frequent input and output of data in the IOS swap, when generating the first block, the area of the overlapping block is calculated, and the data of these blocks is arranged in the order of the overlapping area to create a drawing index list and the limit allowed by the memory. The U-port map data is uploaded in the order of the overlapping area within them. At this point, only the largest number can be placed in the drawing index list, except for the largest area, so that the rest of the work order does not matter much first. In FIG. 4, since the size of the middle block is the largest, the middle block data is placed on the top, and the drawing starts from the block. When the drawing of the block is finished and the corresponding data is not used, in the list group and the data group The index and data are deleted and the next U portal map data is imported. If only a part of the list group is uploaded without raising all of the indexes, the work proceeds in the order of largest area, and then proceeds as shown in FIG. Normally, the map is drawn around the center of the center, and the drawing work is assigned from the most, and the drawing work is from the most to the least.
Claims (4)
메모리 영역은 인덱스를 저장하는 리스트그룹과 U포털 지도데이터를 저장하는 데이터 그룹으로 나뉘며 로컬스토리지에는 인덱스와 U포털 지도데이터가 함꼐 저장되는데
그리려는 도면을 미리지정된 크기의 블록으로 나누는 블록킹단계와;
나누어진 블록별로 그리기를 하는 그리기단계와;
그리기 단계는 로컬스토리지의 인덱스를 참조하여 실제 디스플레이에 표현되는 그리기영역과 만나는 곳의 인덱스를 리스트그룹에 저장하고 그리기 영역과 만나는 U포털 지도데이터를 데이터그룹에 저장하는 스왑준비단계와
메모리사용율을 참조하여 사용하지 않는 인덱스를 메모리에서 제거하고 또한 사용하지 않는 U포털 지도데이터를 메모리에서 제거하는 스왑제거단계를 포함하며
상기 블록킹단계에서 최초 블록을 생성할 때 표시화면크기와 겹치는 블록의 면적을 계산하고 이들 블록의 데이터를 겹치는 면적의 크기순으로 배열하여 그리기 인덱스리스트를 만들고 메모리가 허용하는 한도내에서 겹치는 면적이 큰 순서대로 해당 U포털 지도데이터를 데이터그룹에 저장하는, 실시간 U포털 지도서비스를 위한 데이터 처리방법
As a data processing method for real-time U portal map service,
The memory area is divided into a list group that stores the index and a data group that stores the U portal map data. The local storage stores the index and the U portal map data together.
A blocking step of dividing a drawing to be drawn into blocks of a predetermined size;
A drawing step of drawing the divided blocks;
The drawing step includes a swap preparation step for storing the index of the location where the drawing area is represented on the actual display in the list group by referring to the index of the local storage, and storing the U-portal map data that meets the drawing area in the data group.
A swap removal step of removing unused indexes from memory by referring to memory utilization and removing unused U-Portal map data from memory;
When creating the first block in the blocking step, calculate the area of the overlapping blocks with the display screen size, arrange the data of these blocks in the order of the overlapping area, create a drawing index list, and make the overlapping area as large as the memory allows. Data processing method for real-time U portal map service, which stores corresponding U portal map data in data group in order
제1항에 있어서, 메모리 사용율이 95%이상을 넘으면 스왑제거단계를 실시하고, 메모리 사용율이 70%이하인 경우 새로운 U포털 지도데이터를 가져오는 단계를 실시하는 것을 그리기가 완료될때까지하는 것을 특징으로 하는,실시간 U포털 지도서비스를 위한 데이터 처리방법
The method of claim 1, wherein if the memory usage exceeds 95%, the swap removal step is performed, and if the memory usage is 70% or less, performing a step of bringing new U-Portal map data until drawing is completed. Data processing method for real-time U-Portal map service
제2항에 있어서, 두 개이상의 CPU코어를 포함하는 경우 CPU코어마다 별도의 그리작업을 실행하는 것을 특징으로 하는, 실시간 U포털 지도서비스를 위한 데이터 처리방법
The data processing method for real-time U-portal map service according to claim 2, characterized in that a separate drawing operation is executed for each CPU core when the CPU core includes two or more CPU cores.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020110084871A KR101187537B1 (en) | 2011-08-25 | 2011-08-25 | Method of managing data for real time u-portal map service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020110084871A KR101187537B1 (en) | 2011-08-25 | 2011-08-25 | Method of managing data for real time u-portal map service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR101187537B1 true KR101187537B1 (en) | 2012-10-02 |
Family
ID=47287319
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020110084871A KR101187537B1 (en) | 2011-08-25 | 2011-08-25 | Method of managing data for real time u-portal map service |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR101187537B1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102337794B1 (en) | 2021-04-28 | 2021-12-08 | 우형제 | Data portal service system and construction method thereof |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002324069A (en) | 2001-04-25 | 2002-11-08 | Dream Technologies Kk | Data management apparatus and map display system |
-
2011
- 2011-08-25 KR KR1020110084871A patent/KR101187537B1/en active IP Right Grant
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002324069A (en) | 2001-04-25 | 2002-11-08 | Dream Technologies Kk | Data management apparatus and map display system |
Non-Patent Citations (1)
| Title |
|---|
| 이승환 외 2인, ‘플래시 메모리를 위한 페이지 비율 분석 기반의 적응적 가비지 컬렉션 정책,’ 정보과학회논문지, vol. 36, no. 5, pp. 422-428, 2009.10.31. |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102337794B1 (en) | 2021-04-28 | 2021-12-08 | 우형제 | Data portal service system and construction method thereof |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9807145B2 (en) | Adaptive tile framework | |
| RU2632128C1 (en) | Method and system of downloading image fragments to client device | |
| CN103473732A (en) | Mobile GIS (Geographic Information System) slice map showing method based on concurrent control and double-cache technologies | |
| US9626285B2 (en) | Storage resource allocation to dataflows based on data requirements and attributes | |
| KR101641179B1 (en) | Distributed processing method and server for processing mass geographic data | |
| US9355106B2 (en) | Sensor data locating | |
| CN106201673B (en) | A kind of seismic data processing technique and device | |
| CN109729423A (en) | A kind of desktop wallpaper setting method and device | |
| CN106569805B (en) | Canvas storage method, picture drawing method and equipment | |
| US20230097620A1 (en) | Memory management in graphics and compute application programming interfaces | |
| CN112181663A (en) | Memory scheduling method and device and computer equipment | |
| CN105354090B (en) | The management method and device of virtual unit | |
| CN104967807A (en) | Caching method and apparatus | |
| CN102932416B (en) | A kind of intermediate data storage method of information flow task, processing method and device | |
| CN103324484A (en) | Method and device for displaying view | |
| CN103020201A (en) | Storage pool capable of automatically simplifying configuration for storage system and organization and management method | |
| KR101187537B1 (en) | Method of managing data for real time u-portal map service | |
| DE202021102320U1 (en) | System for implementing sub-database replication | |
| CN103093040A (en) | Engineering application method for network map image | |
| CN108986034B (en) | Raster data coordinate conversion method, system, terminal equipment and storage medium | |
| CN105512312A (en) | Accelerating method for two-dimensional map library | |
| KR102157591B1 (en) | Apparatus for Spatial Query in Big Data Environment and Computer-Readable Recording Medium with Program therefor | |
| CN111552740B (en) | Data processing method and device | |
| CN104392410A (en) | Method and equipment for integrating pictures in skin system and skin drawing method | |
| EP3418914A1 (en) | Data management apparatuses, methods, and non-transitory tangible machine-readable media thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| A302 | Request for accelerated examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20150917 Year of fee payment: 4 |
|
| FPAY | Annual fee payment |
Payment date: 20171027 Year of fee payment: 6 |
|
| FPAY | Annual fee payment |
Payment date: 20180726 Year of fee payment: 7 |
|
| FPAY | Annual fee payment |
Payment date: 20190715 Year of fee payment: 8 |